Gitlab MCP Server
by jmrplens
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITLAB_URL | No | GitLab instance URL (default: https://gitlab.com; set for self-managed instances) | https://gitlab.com |
| GITLAB_TOKEN | Yes | GitLab Personal Access Token (glpat-...) | |
| GITLAB_MCP_TIER | No | GitLab tier: free/ce, premium or ultimate, used as given. When unset, detected from the instance license, then from the plans of the namespaces the token administers, falling back to free. Gates Premium and Ultimate actions; GitLab.com Ultimate also serves the Orbit Knowledge Graph tools | |
| GITLAB_MCP_LOG_LEVEL | No | Logging verbosity (default: info) | info |
| GITLAB_MCP_READ_ONLY | No | Read-only mode: removes every mutating action from the served surface; reads keep working (default: false) | false |
| GITLAB_MCP_SAFE_MODE | No | Safe mode: a mutating action returns a preview card naming the action and echoing its arguments instead of running; reads keep working (default: false) | false |
| GITLAB_MCP_TOOL_SURFACE | No | Tool catalog selector: dynamic, meta, or individual (default: dynamic) | dynamic |
| GITLAB_MCP_EXCLUDE_TOOLS | No | Comma-separated tool names, group names or canonical action IDs to exclude, on every surface (e.g. gitlab_admin,gitlab_runner) | |
| GITLAB_MCP_IGNORE_SCOPES | No | Skip the scope filter and the read_api narrowing and register all tools regardless of token permissions; a token carrying neither read_api nor api is still refused (default: false) | false |
| GITLAB_MCP_RATE_LIMIT_RPS | No | Rate limit per credential, in requests per second, on every call that reaches GitLab, with tools/list charged to a bucket of its own; 0, the default on stdio, disables it (default: 0) | 0 |
| GITLAB_MCP_SKIP_TLS_VERIFY | No | Skip TLS certificate verification for self-signed certs (default: false) | false |
| GITLAB_MCP_RATE_LIMIT_BURST | No | Token-bucket burst size when GITLAB_MCP_RATE_LIMIT_RPS is greater than 0 (default: 40) | 40 |
| GITLAB_MCP_META_PARAM_SCHEMA | No | Meta-tool input schema detail: opaque, compact, or full (default: opaque) | opaque |
| GITLAB_MCP_CAPABILITY_SURFACE | No | Resource and prompt catalog selector: full or minimal (default: full); resource subscriptions require full | full |
| GITLAB_MCP_EMBEDDED_RESOURCES | No | Append EmbeddedResource content blocks (clickable links to MCP resources) to get_* tool results (default: true) | true |
| GITLAB_MCP_ALLOWED_IMPORT_DIRS | No | Extra OS path-list-separated directories a project or group import archive may be read from; the working directory (unless it is the filesystem root or your home directory) and the OS temp directory are always allowed. Unused in HTTP mode, which refuses local paths | |
| GITLAB_MCP_ALLOWED_UPLOAD_DIRS | No | Extra OS path-list-separated directories an action may read a local file from; the working directory (unless it is the filesystem root or your home directory) and the OS temp directory are always allowed. Unused in HTTP mode, which refuses local paths | |
| GITLAB_MCP_UPLOAD_MAX_FILE_SIZE | No | Largest local file an upload or file-reading action accepts, in bytes or with a KB, MB or GB suffix (e.g. 2GB); at most 1 TB (default: 2147483648, 2 GB) | 2147483648 |
| GITLAB_MCP_ALLOWED_DOWNLOAD_DIRS | No | Extra OS path-list-separated directories an action may write a downloaded file into; the working directory (unless it is the filesystem root or your home directory) and the OS temp directory are always allowed. Unused in HTTP mode, which refuses local paths |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gitlab_execute_actionA | Execute one GitLab catalog action by canonical ID or alias. Always pass params as an object. Destructive actions require top-level confirm=true. Use find first only when action or params are unclear. Example: {"action":"issue.list","params":{"project_id":"group/project"}} |
| gitlab_find_actionA | Search the local GitLab action catalog. Read-only and no GitLab API call. Use when the action ID or params are unclear. Returns schemas, hints, destructive flags, and execute examples. Example: {"query":"issue list"} |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit_commit_hygiene | Audit commit message quality between two refs. Scores Conventional Commit usage, merge commits, breaking-change markers, body/detail quality, and linked work references for release and contribution readiness. |
| audit_project_full | Audit a GitLab project in one report: a quick scorecard, then settings, branch protection, access management, labels, active milestones, templates, webhooks, and push rules, up to 100 per list. Use this for a complete project health assessment with actionable recommendations. |
| audit_project_workflow | Audit workflow configuration for a GitLab project: labels (names, colors, descriptions, open issue/MR counts), milestones (open/closed, due dates), and issue/MR templates, up to 100 per list. Identifies gaps like labels without descriptions, milestones without due dates, or missing templates. |
| branch_mr_summary | List up to 100 MRs targeting a specific branch in a project. Shows a readiness summary with total, draft and conflict counts. Ideal for release branch reviews. |
| compare_branches | Compare commit and file differences between two Git refs. Use for release branch preparation, feature branch divergence analysis, or deciding whether a merge/backport needs deeper review. |
| daily_standup | Generate a daily standup summary for a user: contribution events of the last 24 hours, and the project's open MRs they authored, are assigned or review and open issues assigned to or created by them, up to 100 per list. Produces a report with done/planned/blockers sections. |
| generate_release_notes | Generate release notes from the commits, file changes, and merge requests between two Git refs (tags, branches, or SHAs). Produces a structured document with the commits, up to 100 MRs merged around the commits' dates with their labels, contributors, and statistics for organizing into user-friendly release notes. |
| group_milestone_progress | Track the progress of up to 100 active group milestones across the group's projects. Shows issue/MR completion per milestone with progress bars, reading up to 100 issues and 100 MRs of each. |
| group_mr_dashboard | List up to 100 merge requests across a GitLab group with optional state and target branch filters. Shows MRs grouped by project with blocker and readiness summary statistics. |
| label_distribution | Analyze label usage distribution in a project from up to 100 labels. Shows open/closed issue counts and open MR counts per label. Zero additional API calls beyond the label list. |
| merge_velocity | Analyze MR throughput for a project from up to 100 MRs created in the period and since merged. Shows merge rate, average and median time-to-merge, and a daily merged count chart. Ideal for tracking team delivery pace. |
| milestone_progress | Track milestone progress for a project. Shows issue/MR completion, progress bar, and due date risk, reading up to 100 issues and 100 MRs of each milestone. Omit the milestone argument to see up to 100 active milestones. |
| mr_description_quality | Score a merge request description for reviewer readiness. Checks context, linked work, test evidence, rollout/risk notes, checklists, and whether up to 100 changed files suggest missing screenshots or migration notes. |
| mr_discussion_health | Analyze unresolved discussion threads across up to 20 open MRs in a project, the most recently created first, reading up to 100 discussions of each. Use this for review follow-up and merge-readiness cleanup, not approval-rule status. |
| mr_risk_assessment | Assess the risk level (LOW/MEDIUM/HIGH/CRITICAL) of a merge request from up to 100 changed files: size (lines added/removed), number of changed files, new/deleted files, sensitive file patterns (env, auth, migration, CI, security), and conflict status. |
| my_activity_summary | Generate a personal activity summary for a configurable period, across all projects: contribution events by action, the counts of MRs authored that were created in the period and merged and of MRs reviewed that were updated in it, and a daily activity chart, up to 100 per list. |
| my_issues | Show up to 100 issues assigned to you across all projects. Includes overdue detection and project grouping. Use this to see your issue backlog without specifying a project. |
| my_open_mrs | Show the open merge requests across all projects where you are author or assignee, up to 100 of each. Results are grouped by project for easy scanning. Use this to get a personal MR dashboard without specifying a project. |
| my_pending_reviews | Show up to 100 open merge requests across all projects where you are assigned as reviewer. Helps track which MRs are waiting for your review. Results grouped by project. |
| project_activity_report | Generate a project activity report: the counts of events, open MRs, open issues and MRs created in the period and merged, event and contributor breakdowns, a table of those merged MRs, and a daily activity chart, up to 100 per list. |
| project_contributors | Rank up to 100 project contributors by commits, additions, and deletions. Uses the repository contributors API for accurate stats. |
| project_health_check | Project health assessment combining the latest pipeline of the default branch (the newest on the branch when the commit at its head has none, saying so), up to 100 open merge requests, and branch hygiene (merged/stale counts among up to 100 branches). Provides actionable recommendations for project maintenance. |
| release_cadence | Analyze release frequency for a project from its up to 100 most recent releases. Shows the time between the releases of the period, average and median cadence, and a release history table. |
| release_readiness | Check readiness of a release branch from up to 100 open MRs targeting it: draft/conflict counts, and the unresolved discussion threads among up to 100 discussions of each. |
| review_mr | Generate a structured code review for a merge request, reading up to 100 changed files. Files are categorized by risk (high-risk, business logic, tests, documentation) with per-file metrics, branch context, and a review plan. The diff of each file read is included without truncation. |
| reviewer_workload | Analyze review distribution across up to 100 direct members of a group, from up to 100 open group MRs. Shows how many of them each member is reviewing and identifies imbalances. Useful for managers to ensure fair review distribution. |
| stale_items_report | Find up to 100 open MRs and 100 open issues in a project that haven't been updated for a configurable number of days. Helps identify forgotten or blocked items. |
| suggest_mr_reviewers | Suggest suitable merge request reviewers based on up to 100 changed files and the active ones among up to 100 project members, inherited members included. Excludes the MR author and asks the model to consider ownership, approval-rule fit, and workload balance. |
| summarize_mr_changes | Summarize the changed files and key modifications in a merge request, reading up to 100 changed files. Lists each file with its change type (new/modified/deleted/renamed). Use this to quickly understand the scope of a merge request. |
| summarize_open_mrs | Summarize up to 100 open merge requests in a project, the most recently created first, including title, author, branches, age in days, and merge status. Highlights stale MRs (>7 days) and blockers. For one target branch, use branch_mr_summary. |
| summarize_pipeline_status | Summarize the latest CI/CD pipeline of a project's default branch, or the newest pipeline on the branch when the commit at its head has none, saying so. Groups up to 100 of its jobs by outcome (failed/passed/other) and includes failure reasons for debugging. |
| team_member_workload | Generate a workload summary for a team member over a configurable period: contribution events, the project's open MRs they authored, are assigned or review, MRs they authored that were created in the period and merged, and open authored and assigned issues, up to 100 per list. Use this for team management and capacity planning. |
| team_overview | Generate a team dashboard of up to 100 direct members of a group, each with the counts of their open MRs, of the open MRs they review and of their MRs created in the period and merged, from up to 100 open group MRs and 100 created in the period and merged. Includes a workload distribution pie chart. Requires a GitLab group ID. |
| unassigned_items | Find up to 100 open MRs and 100 open issues in a project that have no assignee. Helps identify ownership gaps and items needing attention. |
| user_activity_report | Generate an activity report for a user: contribution events, MRs they authored that were created in the period and merged, open MRs they review that were updated in it, and a daily activity chart, up to 100 per list. Designed for managers to review team member productivity. |
| user_stats | Generate statistics for a user: contribution events across all projects with their breakdown, daily activity trends and a Mermaid activity chart, and the project's merge request stats (authored/assigned/reviewed by state) and issue stats (authored/assigned by state), up to 100 per list. Use this for performance reviews, productivity tracking, or personal dashboards. |
| weekly_team_recap | Generate a weekly recap for a team: MRs created in the period and merged, by project, open MR and open issue counts, and open MR health (drafts, conflicts), all as tables, up to 100 per list. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| groups | Groups accessible to the authenticated user, up to one page (100). Returns each group's ID, name, full path, description, visibility level, and web URL. |
| code_review | Code review checklist and best practices for GitLab merge request reviews. |
| conventional_commits | Conventional commit message format and examples for consistent Git history. |
| git_workflow | Best practices for Git branching strategies with GitLab (feature branches, trunk-based, GitLab Flow). |
| merge_request_hygiene | Guidelines for creating and reviewing high-quality merge requests. |
| pipeline_troubleshooting | Common GitLab CI/CD pipeline issues and how to diagnose and fix them. |
| tool_manifest | Surface-aware manifest of the tools and executable actions available in this server instance. Use gitlab://tools/{id} to fetch one entry's accepted call shape and input schema. |
| current_user | Get the currently authenticated GitLab user profile. Returns username, display name, email, state (active/blocked), admin status, and web URL. |
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct roles: gitlab_find_action is read-only catalog search, while gitlab_execute_action performs an action. There is no ambiguity about which tool to use, and the descriptions explicitly state when to use each.
Naming Consistency5/5
Both names follow the same gitlab_<verb>_action pattern, using consistent snake_case and predictable verbs (find, execute). The convention is immediately clear across the set.
Tool Count4/5
Two tools is thin in absolute terms, but here they act as a deliberate gateway exposing a large GitLab action catalog. The meta-tool pattern keeps the surface small and well-scoped rather than being an underbuilt server.
Completeness4/5
The execute tool can run any canonical catalog action, and the find tool supports discovery with schemas and hints, so the surface is broad and lifecycle coverage depends on the catalog. Minor gaps may exist if the catalog is incomplete, but destructive-action confirmation and discovery are handled.
Maintenance
ActivityActive
ResponsivenessResponsive