MCP server card

gitlab

GitLab MCP Server

Free hosted GitLab MCP endpoint, no account beyond your own gitlab.com token, never written to disk. Over 700 operations: projects, MRs, pipelines.

Connect it to your client

Sign in with OAuth (recommended)

Your client opens gitlab.com in the browser, you authorize it there, and it stores the token itself — you never paste one. The client ID has to be configured explicitly: without it these clients fall back to dynamic registration, which GitLab answers with a scope this server cannot use.

Claude Code

claude mcp add gitlab --transport http \
  --client-id c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941 \
  --callback-port 8090 \
  https://mcp.jmrp.io/gitlab

Cursor — ~/.cursor/mcp.json

{
  "mcpServers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "oauth": {
        "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941",
        "scopes": [
          "api"
        ]
      }
    }
  }
}

VS Code — .vscode/mcp.json

{
  "servers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "oauth": {
        "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941",
        "scopes": [
          "api"
        ]
      }
    }
  }
}

Or paste a token

For anything that cannot open a browser — headless, CI — a gitlab.com personal access token sent as Bearer is verified exactly like an OAuth one.

Claude Code

claude mcp add --transport http gitlab \
  https://mcp.jmrp.io/gitlab \
  --header "Authorization: Bearer <your token>"

Cursor — ~/.cursor/mcp.json

{
  "mcpServers": {
    "gitlab": {
      "url": "https://mcp.jmrp.io/gitlab",
      "headers": {
        "Authorization": "Bearer ${env:GITLAB_TOKEN}"
      }
    }
  }
}

VS Code — .vscode/mcp.json

{
  "inputs": [
    {
      "type": "promptString",
      "id": "gitlab-token",
      "description": "Your gitlab.com credential, sent as Bearer: an OAuth access token, or a personal access token used the same way. Never written to disk or logged on the server.",
      "password": true
    }
  ],
  "servers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "headers": {
        "Authorization": "Bearer ${input:gitlab-token}"
      }
    }
  }
}

In the JSON files the ${…} placeholders keep the credential out of the file: Cursor reads it from your environment, VS Code prompts for it once and stores it itself. In the command, replace <your token> by hand.

Before you rely on this

This endpoint is a personal service, run by one person and offered as-is: no SLA, no support channel, and no promise it is still here — or unchanged — next week. Both servers are open source and ship as a single static binary, so anything you cannot afford to lose is better run on your own instance.

Each credential gets 60 calls a second to GitLab per instance, in bursts of up to 40, and repeated failed sign-ins block the address for a while. Beyond that, every call is spent against gitlab.com's limits, under your own token.

Behind the endpoint are three instances of this server. A consistent hash keeps sending the same client back to the same one, and each instance leaves for the outside world through its own exit node, in Spain or the United Kingdom: How a request is routed, hop by hop

What is logged and for how long, where a request appears to come from, and the legal footing under all of it are set out in full: Privacy, logging and legal position

Does gitlab cost anything, and do I need an account?

The endpoint is free and there is nothing here to sign up for. What it needs is a gitlab.com account you already have, because the server acts as you: it holds no account of its own and issues no credential, so there is no key to request and no plan to pick.

Whatever quota you spend is your own on gitlab.com, and what you can reach is whatever that token can reach — this server adds no tier of its own.

Where does your GitLab token go?

Your token stays in your browser's memory only. It is not written to localStorage or cookies, never travels in the URL, and is gone on reload. It is sent solely as an Authorization: Bearer header to mcp.jmrp.io/gitlab, which never writes it to disk or logs it: the server keeps it in memory only while you keep using it — up to an hour after your last call — and then drops it.

The destination is not a matter of trust: this page's Content-Security-Policy declares connect-src 'self' https://gitlab.com and form-action 'self', so the browser itself refuses to send the token anywhere but this domain and the one that issues it. gitlab.com is on that list for exactly one reason — the sign-in button, which exchanges an authorization code for a token issued to the inspector's own OAuth application, scoped to read_api and nothing wider — and for nothing else. What the server then does with it — keep it in memory while you use it, re-check it with gitlab.com every fifteen minutes, and drop it — you can verify in its source code, which is public.

Even so, be suspicious of any site asking for a token — this one included. The sensible habits are:

Verify it yourself: this page's source is public, and so is the server's.
Use the narrowest credential that does what you need. A token scoped to read_api is admitted and served exactly the actions GitLab accepts from that scope, which are reads: it cannot break anything, and it is the right one for trying the server out. api is only needed to reach the actions that write. Narrower still is a GitLab fine-grained token, limited to the projects and permissions you pick: the server serves it only what its grant reaches, and turns it away at the door unless the grant includes User: Read. The server decides per action, not once at the door, so asking for less is served less rather than refused.
Revoke it when you are done testing.
Never reuse a token you rely on in production.

How that hash is derived, with the code

What are gitlab's rate limits and availability?

The gitlab endpoint at mcp.jmrp.io is likewise personal, with no SLA and no continuity guarantee. For anything critical, run your own instance — the server is open source and ships as one static binary.

Each credential has its own budget on each of the three instances: 60 calls a second that reach GitLab, in bursts of up to 40, with listing the catalogue on a separate bucket that refills a tenth as fast. Past that, what you spend is gitlab.com's quota, under your own token.

Failed sign-ins are counted per address. Ten in a minute block that address until the minute is out; fifty different rejected tokens in ten minutes block it for a minute, then ten, then an hour at a time. A client retrying one expired token recovers on its own; one trying token after token does not.

Overview

Server name: gitlab-mcp-server
Version: 3.2.0
Endpoint: https://mcp.jmrp.io/gitlab
Authentication: Credentials required (oauth2)

In the server's own words: Model Context Protocol server for GitLab: projects, issues, merge requests, pipelines, repositories, releases, groups, and admin workflows over the GitLab REST and GraphQL APIs.

Try in the inspector Repository Documentation Official website

Usage instructions

What the server itself tells every client on connect (server/discover), quoted verbatim.

gitlab-mcp-server exposes GitLab projects, merge requests, issues, branches, tags, releases, repositories, commits, files, groups, members, and uploads.

FINDING TOOLS. This server exposes two tools that reach the whole GitLab API:
1. Call gitlab_find_action with a natural-language description of the task to get matching action IDs and their input schemas.
2. Call gitlab_execute_action with that action ID, its parameters under 'params'.
3. Every action="..." named below is a canonical action ID: pass it to gitlab_execute_action directly, no find step needed.

PROJECT DISCOVERY. To find the project_id needed for most operations:
1. Read the .git/config file from the workspace to find [remote "origin"] url = ...
2. Call action="discover_project.resolve" with that URL to get the project_id.
3. Alternatively, use action="project.list" (owned=true) or action="search.projects" to find projects by name.

DEFAULT BRANCH. When generating URLs to repository files or branches:
1. Call action="project.get" to retrieve the project metadata, which includes the default_branch field.
2. ALWAYS use the returned default_branch value (e.g. develop, master) instead of assuming 'main'.
3. Projects can use any branch as default, so NEVER hardcode 'main' in URLs.

PACKAGE + RELEASE WORKFLOW. When uploading packages and linking them to releases:
1. Preferred: Use action="package.publish_and_link" to upload a file and create the release link in one step.
2. Alternative: Use action="package.publish" first, then use the 'url' field from its response as the URL for action="release.link_create".
3. NEVER construct package download URLs manually. Always use the actual URL returned by the publish tool.
4. RELEASE LINK NAMING: The link_name MUST be the exact filename (e.g. 'checksums.txt.asc'), NEVER add descriptive suffixes like '(GPG signature)'. go-selfupdate and other tools match asset names exactly.

RELEASE CREATION. When creating releases:
1. You do NOT need to create the tag first. Provide 'ref' (branch or SHA) in action="release.create" and GitLab auto-creates the tag.
2. The response includes 'assets_sources' with auto-generated tar.gz/zip archive URLs. Use those, never construct source archive URLs.
3. Use 'tag_message' to create an annotated tag instead of a lightweight one.

ID vs IID. GitLab uses two identifiers for issues and merge requests:
1. IID is the project-scoped number shown in URLs and UI (e.g. issue #3, MR !5). Most operations expect IID.
2. ID is the global numeric identifier. Only use action="issue.get_by_id" when you have a global ID from another API response.

WATCHING RESOURCES. Instead of re-reading a resource in a loop to detect change:
1. Single-object resources (a pipeline, an issue, a merge request, a file, a wiki page, ...) can be watched for change notifications via MCP subscriptions/listen, which protocol revision 2026-07-28 introduced (a client speaking an earlier revision cannot watch resources on this transport: the legacy resources/subscribe is refused here, because each request's session ends with its response); collections (issue lists, branch lists) cannot.
2. Example: subscribe to gitlab://project/{project_id}/pipelines/latest to be notified when a pipeline's state changes, instead of polling it yourself. The server watches GitLab and sends notifications/resources/updated only when the content actually changed.

Tools(2)

GitLab Execute Action

gitlab_execute_action

destructive
open world

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

Arguments (3 fields)

action string · required: Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close.
params object · required: Required action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters.
confirm boolean: Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action.

What it returns (2 fields)

next_steps string[]: Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
pagination object: Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`.

Try in the inspector

GitLab Find Action

gitlab_find_action

read-only
idempotent
open world

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

Arguments (3 fields)

query string · required: Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. At most 256 characters: a longer query is refused, not truncated.
explain boolean: When true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact.
limit integer: Maximum number of matches to return. Defaults to 20 and is capped at 50.

What it returns (3 fields)

count integer: Number of returned matches.
query string: Original search query.
results object[]: Matching GitLab catalog actions with schemas and execute examples.

Try in the inspector

Action catalog (768)

Behind the tools above sits a catalog of fine-grained actions, invoked through gitlab_execute_action and published as the gitlab://tools resource. This table only counts it, by domain — the full list is the resource itself.

Counted with a Free-tier token against gitlab.com, which is the only host this endpoint talks to: to use it against a self-managed instance, run the server yourself — its documentation covers that. The catalog is scoped to the token that asks, so the count moves with both its tier and its permissions: higher tiers expose more actions, and administration domains only appear to tokens allowed to use them. That is why the figures differ elsewhere: the upstream project counts 868 operations on Community Edition and up to 1,094 on GitLab.com's top tier, while this deployment publishes 768 because it is OAuth-only and acts with your token, so the administration domains a non-admin account cannot call never appear. All three describe the same catalog, counted from three vantage points.

Actions by domain
Domain	Actions	Destructive	Read-only
`project`	124	25	51
`user`	76	14	37
`group`	75	12	33
`issue`	66	8	33
`access`	48	9	19
`merge_request`	46	7	23
`repository`	41	2	27
`snippet`	34	6	17
`pipeline`	33	4	15
`package`	30	8	12
`job`	25	5	13
`mr_review`	23	3	10
`runner`	19	4	8
`environment`	18	4	7
`ci_variable`	15	3	6
`achievement`	12	3	4
`release`	12	2	5
`template`	12	0	12
`branch`	11	3	5
`feature_flags`	10	2	4
`search`	10	0	10
`tag`	9	2	5
`wiki`	6	1	2
`interactive`	4	0	0
`custom_emoji`	3	1	1
`ci_catalog`	2	0	2
`server`	2	0	2
`discover_project`	1	0	1
`model_registry`	1	0	1

Prompts (37)

Canned plans a client can render, beyond the tools above. Ask your assistant for one by name.

Audit Commit Hygiene

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
from · required: Starting ref: tag name, branch name, or commit SHA
to: Ending ref: tag name, branch name, or commit SHA (defaults to HEAD if omitted)

Try in the inspector

Audit Project Full

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Audit Project Workflow

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Branch MR Summary

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
target_branch · required: Target branch name to filter MRs (e.g. 'develop_5.4.0')
state: State filter: opened, closed, merged, all (default: opened)

Try in the inspector

Compare Branches

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
from · required: Source branch name, tag, or commit SHA to compare from
to · required: Target branch name, tag, or commit SHA to compare to

Try in the inspector

Daily Standup

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
username: GitLab username to generate the standup for (defaults to the authenticated user if omitted)

Try in the inspector

Generate Release Notes

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
from · required: Starting ref: tag name (e.g. 'v1.0.0'), branch name, or commit SHA
to: Ending ref: tag name, branch name, or commit SHA (defaults to HEAD if omitted)

Try in the inspector

Group Milestone Progress

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_id · required: GitLab group ID (numeric) or full path as written (e.g. 'my-group' or 'parent/child'), not URL-encoded

Try in the inspector

Group MR Dashboard

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.

group_id · required: GitLab group ID (numeric) or full path as written (e.g. 'my-group' or 'parent/child'), not URL-encoded
state: State filter: opened, closed, merged, all (default: opened)
target_branch: Target branch name to filter MRs (e.g. 'develop_5.4.0')

Try in the inspector

Label Distribution

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Merge Velocity

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
days: Number of days to look back, a positive integer (default: 30)

Try in the inspector

Milestone Progress

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
milestone: Specific milestone title (omit for every active milestone, up to 100)

Try in the inspector

MR Description Quality

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
merge_request_iid · required: Merge request IID (project-scoped numeric ID, visible as !N in GitLab)

Try in the inspector

MR Discussion Health

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

MR Risk Assessment

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
merge_request_iid · required: Merge request IID (project-scoped numeric ID, visible as !N in GitLab)

Try in the inspector

My Activity Summary

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.

username: GitLab username to query (defaults to the authenticated user if omitted)
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

My Issues

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.

username: GitLab username to query (defaults to the authenticated user if omitted)
state: State filter: opened, closed, all (default: opened)

Try in the inspector

My Open MRs

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.

username: GitLab username to query (defaults to the authenticated user if omitted)

Try in the inspector

My Pending Reviews

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.

username: GitLab username to query (defaults to the authenticated user if omitted)

Try in the inspector

Project Activity Report

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_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

Project Contributors

project_contributors

Rank up to 100 project contributors by commits, additions, and deletions. Uses the repository contributors API for accurate stats.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Project Health Check

project_health_check

Project health assessment combining the latest pipeline of the default branch, up to 100 open merge requests, and branch hygiene (merged/stale counts among up to 100 branches). Provides actionable recommendations for project maintenance.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Release Cadence

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
days: Number of days to look back, a positive integer (default: 90)

Try in the inspector

Release Readiness

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
branch: Target release branch (default: main)

Try in the inspector

Review MR

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
merge_request_iid · required: Merge request IID (project-scoped numeric ID, visible as !N in GitLab)

Try in the inspector

Reviewer Workload

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.

group_id · required: GitLab group ID (numeric) or full path as written (e.g. 'my-group' or 'parent/child'), not URL-encoded

Try in the inspector

Stale Items Report

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
stale_days: Days without update to consider stale, a positive integer (default: 14)

Try in the inspector

Suggest MR Reviewers

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
merge_request_iid · required: Merge request IID (project-scoped numeric ID, visible as !N in GitLab)

Try in the inspector

Summarize MR Changes

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
merge_request_iid · required: Merge request IID (project-scoped numeric ID, visible as !N in GitLab)

Try in the inspector

Summarize Open MRs

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Summarize Pipeline Status

summarize_pipeline_status

Summarize the latest CI/CD pipeline of a project's default branch. Groups up to 100 of its jobs by outcome (failed/passed/other) and includes failure reasons for debugging.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

Team Member Workload

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
username · required: GitLab username of the team member to analyze
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

Team Overview

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.

group_id · required: GitLab group ID (numeric) or full path as written (e.g. 'my-group' or 'parent/child'), not URL-encoded
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

Unassigned Items

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded

Try in the inspector

User Activity Report

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.

username · required: GitLab username to report on
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

User Stats

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.

project_id · required: Project ID (numeric) or full path as written (e.g. 'group/project'), not URL-encoded
username: GitLab username to generate stats for (defaults to the authenticated user if omitted)
days: Number of days to look back, a positive integer (default: 30)

Try in the inspector

Weekly Team Recap

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.

group_id · required: GitLab group ID (numeric) or full path as written (e.g. 'my-group' or 'parent/child'), not URL-encoded
days: Number of days to look back, a positive integer (default: 7)

Try in the inspector

Resources (8)

All Groups

gitlab://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.

Type: application/json

Try in the inspector

Code Review Guide

gitlab://guides/code-review

Code review checklist and best practices for GitLab merge request reviews.

Type: text/markdown

Try in the inspector

Conventional Commits Guide

gitlab://guides/conventional-commits

Conventional commit message format and examples for consistent Git history.

Type: text/markdown

Try in the inspector

Git Workflow Guide

gitlab://guides/git-workflow

Best practices for Git branching strategies with GitLab (feature branches, trunk-based, GitLab Flow).

Type: text/markdown

Try in the inspector

Merge Request Hygiene Guide

gitlab://guides/merge-request-hygiene

Guidelines for creating and reviewing high-quality merge requests.

Type: text/markdown

Try in the inspector

Pipeline Troubleshooting Guide

gitlab://guides/pipeline-troubleshooting

Common GitLab CI/CD pipeline issues and how to diagnose and fix them.

Type: text/markdown

Try in the inspector

Tool Manifest

gitlab://tools

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.

Type: application/json

Try in the inspector

Current User Profile

gitlab://user/current

Get the currently authenticated GitLab user profile. Returns username, display name, email, state (active/blocked), admin status, and web URL.

Type: application/json

Try in the inspector

Resource templates (37)

Parameterised resources: the same shape as the resources above, with a placeholder in the URI a client fills in before reading it.

Group Details

gitlab://group/{group_id}

subscribable

Get details for a specific GitLab group by numeric ID or URL-encoded path. Returns name, full path, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Group Label Details

gitlab://group/{group_id}/label/{label_id}

subscribable

Get details for a single group label by numeric ID or name. Returns id, name, color, and description. Usage counts come from group.group_label_list with with_counts. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Group Members

gitlab://group/{group_id}/members

Members of a GitLab group, up to one page (100), with their access levels (10=guest, 20=reporter, 30=developer, 40=maintainer, 50=owner). Includes inherited members.

Type: application/json

Group Milestone Details

gitlab://group/{group_id}/milestone/{milestone_iid}

subscribable

Get details for a single group milestone by IID. Returns id, iid, title, description, state, due date, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Group Projects

gitlab://group/{group_id}/projects

Projects within a GitLab group, up to one page (100). Returns each project's ID, name, namespace path, visibility, web URL, description, and default branch.

Type: application/json

Project Metadata

gitlab://project/{project_id}

subscribable

Get basic metadata for a GitLab project by numeric ID or URL-encoded path. Returns name, namespace path, visibility, web URL, description, and default branch. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Board Details

gitlab://project/{project_id}/board/{board_id}

subscribable

Get details for a single project issue board by numeric ID. Returns id and name. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Branch Details

gitlab://project/{project_id}/branch/{branch}

subscribable

Get details for a single repository branch. Returns name, protection status, merge status, default flag, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Branches

gitlab://project/{project_id}/branches

Branches in a GitLab project, up to one page (100). Returns each branch's name, protection status, merge status, default flag, and web URL.

Type: application/json

Commit Details

gitlab://project/{project_id}/commit/{sha}

Get details for a single commit by SHA. Returns id, short_id, title, message, author and committer names and emails, authored/committed dates, parent commits, web URL, and stats (additions, deletions and their total).

Type: application/json

Deploy Key Details

gitlab://project/{project_id}/deploy_key/{deploy_key_id}

subscribable

Get details for a single project deploy key by numeric ID. Returns id, title, key, and fingerprint. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Deployment Details

gitlab://project/{project_id}/deployment/{deployment_id}

subscribable

Get details for a single project deployment by numeric ID. Returns id, iid, ref, sha, status, and environment name. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Environment Details

gitlab://project/{project_id}/environment/{environment_id}

subscribable

Get details for a single project environment by numeric ID. Returns id, name, slug, state, and tier. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Feature Flag Details

gitlab://project/{project_id}/feature_flag/{name}

subscribable

Get details for a single project feature flag by name. Returns name, description, active, and version. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Repository File

gitlab://project/{project_id}/file/{ref}/{+path}

subscribable

Get the contents of a repository file at a specific ref (branch, tag, or SHA). Path may include slashes. Files over 1 MiB return metadata only with truncated=true. Binary files return metadata with empty content. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Issue Details

gitlab://project/{project_id}/issue/{issue_iid}

subscribable

Get details of a specific issue by its IID (project-scoped ID). Returns title, state, labels, assignees, author, web URL, and creation date. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Issues

gitlab://project/{project_id}/issues

Open issues for a GitLab project, up to one page (100). Returns each issue's IID, title, state, labels, assignees, author, web URL, and creation date.

Type: application/json

Job Details

gitlab://project/{project_id}/job/{job_id}

subscribable

Get details for a single CI job by numeric ID. Returns id, name, stage, status, ref, duration, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Label Details

gitlab://project/{project_id}/label/{label_id}

subscribable

Get details for a single project label by numeric ID or label name. Returns id, name, color, and description. Usage counts come from project.label_list with with_counts. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Labels

gitlab://project/{project_id}/labels

Labels defined in a GitLab project, up to one page (100). Returns each label's name, color, description, and counts of open issues and merge requests using the label.

Type: application/json

Project Members

gitlab://project/{project_id}/members

Members of a GitLab project, up to one page (100), with their access levels (10=guest, 20=reporter, 30=developer, 40=maintainer, 50=owner). Includes inherited members from parent groups.

Type: application/json

Milestone Details

gitlab://project/{project_id}/milestone/{milestone_iid}

subscribable

Get details for a single project milestone by IID. Returns id, iid, title, description, state, due date, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Milestones

gitlab://project/{project_id}/milestones

Milestones in a GitLab project, up to one page (100). Returns each milestone's title, description, state (active/closed), due date, and web URL.

Type: application/json

Merge Request Details

gitlab://project/{project_id}/mr/{merge_request_iid}

subscribable

Get details of a specific merge request by its IID (project-scoped ID). Returns title, state, source/target branches, author, merge status, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Merge Request Discussions

gitlab://project/{project_id}/mr/{merge_request_iid}/discussions

subscribable

List discussion threads on a merge request. Returns up to one page of 100 discussions. A busier merge request has more than this resource shows. Each discussion has an id, individual_note flag, and an array of notes (id, author, body, system, resolved/resolvable, created_at). Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Merge Request Notes

gitlab://project/{project_id}/mr/{merge_request_iid}/notes

subscribable

List notes (comments) on a merge request. Returns up to one page of 100 notes, newest ordering as GitLab returns it. A busier merge request has more than this resource shows. Each note carries id, author username, body, system flag, resolvable/resolved flags, and timestamps. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Pipeline Details

gitlab://project/{project_id}/pipeline/{pipeline_id}

subscribable

Get details of a specific CI/CD pipeline by its numeric ID. Returns pipeline status, ref, SHA, source, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Pipeline Jobs

gitlab://project/{project_id}/pipeline/{pipeline_id}/jobs

subscribable

Jobs for a specific CI/CD pipeline, up to one page (100), including each job's name, stage, status, duration, failure reason (if failed), and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Latest Pipeline

gitlab://project/{project_id}/pipelines/latest

subscribable

Get the latest CI/CD pipeline of a GitLab project's default branch. Returns pipeline ID, status (running/pending/success/failed/canceled), ref, SHA, source, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Release Details

gitlab://project/{project_id}/release/{tag_name}

subscribable

Get details for a single GitLab release by tag name. Returns tag_name, name, description, author, creation/release dates. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Releases

gitlab://project/{project_id}/releases

Releases for a GitLab project, up to one page (100). Returns each release's tag name, name, description, author, and creation/release dates.

Type: application/json

Project Snippet Details

gitlab://project/{project_id}/snippet/{snippet_id}

subscribable

Get details for a single project snippet by numeric ID. Returns id, title, file_name, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Tag Details

gitlab://project/{project_id}/tag/{tag_name}

subscribable

Get details for a single Git tag. Returns name, target commit SHA, annotation message, and protection status. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Project Tags

gitlab://project/{project_id}/tags

Repository tags for a GitLab project, up to one page (100). Returns each tag's name, message, target commit SHA, protection status, and creation date.

Type: application/json

Wiki Page

gitlab://project/{project_id}/wiki/{slug}

subscribable

Get a wiki page by slug. Returns title, slug, format (markdown/rdoc/asciidoc/org), and raw content. Slugs are case-sensitive and use hyphens for spaces. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Snippet Details

gitlab://snippet/{snippet_id}

subscribable

Get details for a single personal/global snippet by numeric ID. Returns id, title, file_name, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.

Type: application/json

Tool Detail

gitlab://tools/{id}

Accepted call shape and input schema for one entry from gitlab://tools. Replace {id} with an entry ID from the active surface, such as project.get in dynamic mode, gitlab_project.get in meta mode, or gitlab_project_get in individual mode.

Type: application/json

Subscriptions

Whether a client can watch a resource for changes instead of polling it, and which of the URI templates above accept a subscription — those carry a chip.

resources/subscribe: Not available on this deployment · requires: stateful sessions (--stateless=false)
subscriptions/listen: Available on this deployment · since protocol 2026-07-28

Subscribable URI templates: 26 / 37

This page was last updated on 10 October 2026

On this page