MCP-gitlab is a token-optimized GitLab MCP server that exposes 5 client tools, enabling discovery and execution of 90 GitLab actions across 14 domains plus eager file/project/commit inspection.
Discover and execute actions: Use gitlab_find_actions to search the 90-action catalog by query/domain, then gitlab_execute_action to run any action with validation and read-only enforcement.
Inspect code and repos: get_file_contents reads files/directories, symbol outlines, or line slices; get_project fetches project metadata; get_commit inspects commit details and selective diffs.
Manage repositories/branches/commits: Search, create, update, delete, or fork projects; manage branches/protection; make atomic multi-file commits; list commit history.
Operate CI/CD: List, trigger, cancel, or retry pipelines; inspect jobs, tail job traces, read artifacts, and get JUnit test reports.
Review merge requests: Create/update/list/merge MRs, inspect changes, manage inline diff discussions, replies, notes, and resolutions.
Plan and track work: Manage issues, issue links/notes, milestones, labels, releases, and tags.
Administer access/config: Manage project members/roles, CI/CD variables, wikis, snippets, and user/group context.
Run enterprise/self-hosted ops: Health checks, push mirrors, runners, and project hooks.
Control safety/output: GITLAB_READ_ONLY blocks writes, GITLAB_EXPOSE_ALL_TOOLS exposes legacy full tool list, and markdown/JSON formats reduce tokens by 75%–99%.
Provides LLM-optimized access to self-hosted GitLab CE/EE and GitLab.com instances, enabling repository and project governance, issue and milestone management, CI/CD pipeline and job inspection, merge request reviews and inline discussions, wiki documentation, snippets, commits, and user/group/project context through the GitLab REST API.
@sumirati/mcp-gitlab)A modern, 2026 AI-native Model Context Protocol (MCP) server for GitLab API v4, engineered for self-hosted GitLab Community Edition (CE), Enterprise Edition (EE), and GitLab.com.
In early MCP servers, dumping 50–100 tools into the client's tool list consumed 10,000+ prompt context tokens on every turn ("System Prompt Tax") and resulted in poor Coherence ratings on the Glama TDQS rubric.
@sumirati/mcp-gitlab v3 solves this with a 5-Tool Hybrid Surface:
Glama TDQS Coherence Tier A (5/5): By exposing exactly 5 tools to the client, the server sits in the ideal 3–15 tool coherence sweet spot.
Ultra-Lean System Prompt Tax: Drops schema overhead from 27,681 tokens to 1,292 tokens (95.3% reduction), preserving context windows and maximizing LLM prompt-cache hits.
Zero-Hop Hourly Drivers: The 3 operations developers and agents actually use constantly during pair-programming (get_file_contents, get_project, get_commit) remain eager tools for instant zero-hop execution.
100% Platform Access on Demand: The entire platform surface of 90 actions across 14 domains is accessible on-demand via dynamic action discovery (gitlab_find_actions $\rightarrow$ gitlab_execute_action), delivering 75%–96% token savings with default high-density Markdown tables and summaries (format: "markdown" | "json").
Resilient Fallback: If an agent directly invokes any catalog action name (e.g. list_pipelines), the server dynamically executes it with full input validation and projection.
LLM Prompt Context (1,292 tokens total):
├── 1. gitlab_find_actions(query, [domain], [format]) [Meta Discovery]
├── 2. gitlab_execute_action(action, params, [format]) [Meta Dynamic Execution]
├── 3. get_file_contents(project_id, file_path, [ref]) [Eager Daily Driver #1]
├── 4. get_project(project_id, [statistics]) [Eager Daily Driver #2]
└── 5. get_commit(project_id, sha) [Eager Daily Driver #3]
Under the hood (Dynamic Registry):
└── 90 Curated Actions across 14 Domains (with 75%–99% token reduction projections)Related MCP server: Context Guardian
Enterprise Observability & Self-Hosted Operations:
System Health Diagnostics: End-to-end connectivity, token identity verification, and API latency testing (system_health_check).
Push Mirrors: Verify upstream replication to remote Git hosts (list_push_mirrors) and force immediate sync (trigger_push_mirror_sync).
CI Runners: Audit runner health, online/paused status, and tags (list_runners, get_runner_status).
Webhooks: Inspect registered automation hooks (list_project_hooks).
Repository & Branch Governance: Project CRUD, group hierarchy resolution (buggycode/project-name), branch lifecycle, branch protection management (list_protected_branches, protect_branch, unprotect_branch), file/directory reading (get_file_contents), and atomic multi-file commits (push_files, create_commit).
CI/CD Observability: Query pipelines by status, trigger/cancel/retry pipelines (create_pipeline, cancel_pipeline, retry_pipeline), tail failed job logs (get_job_trace) without token blowout, read build artifacts (get_job_artifact_file), and inspect JUnit test reports (get_pipeline_test_report).
Merge Request Reviews & Diff Discussions: Two-stage diff inspection (get_merge_request_changes), automated lockfile pruning (package-lock.json), and inline diff discussions with SHA coordinate resolution (create_diff_discussion).
Issues & Task Planning: CRUD issues, track blockers/dependencies (list_issue_links, create_issue_link), and add progress notes (list_issue_notes, create_issue_note).
Milestones & Labels: Human-readable milestone resolution, label creation, and scoped milestone inspection.
Wikis & Snippets: Documentation outline slicing (toc_only: true), chapter extraction, and snippet management.
User & Identity Context: Authenticated identity lookup, group enumeration and creation (create_group), and owned project discovery.
npx (No installation needed)npx -y @sumirati/mcp-gitlabnpm install -g @sumirati/mcp-gitlab
mcp-gitlabgit clone https://github.com/sumirati/mcp-gitlab.git
cd mcp-gitlab
npm install
npm test
npm startVariable | Required | Default | Description |
| Yes | — | Personal access token with |
| No |
| Base API URL of your GitLab CE/EE or cloud instance. |
| No |
| Enable Read-Only safety mode ( |
| No |
| Set to |
| No |
| Default output format ( |
Add to your MCP configuration file (mcp_config.json or claude_desktop_config.json):
{
"mcpServers": {
"gitlab": {
"command": "npx",
"args": ["-y", "@sumirati/mcp-gitlab"],
"env": {
"GITLAB_PERSONAL_ACCESS_TOKEN": "<your-gitlab-token>",
"GITLAB_API_URL": "https://gitlab.example.com/api/v4"
}
}
}
}All 90 actions feature strict input validation and field-mask projections:
Tool | Type | Description |
| Meta | Search and discover available GitLab operations across all 14 domains with compact parameter signatures |
| Meta | Execute any discovered GitLab platform action with input validation and token-optimized projection |
| Eager | Read decoded file contents, symbol outlines, or directory listings from any branch or commit ref without cloning |
| Eager | Retrieve project metadata, project ID, visibility, clone URLs, topics, and default branch |
| Eager | Inspect Git commit details, author info, and token-capped file diffs |
enterprise — 6 actions)Action | Description | Mutating? |
| Perform end-to-end connectivity, latency, and permission diagnostics against the GitLab instance. Verifies API availability, authentication identity, server version/edition (when permitted), and active read-only policy. | No |
| List remote push mirrors configured for a project, including synchronization status, target URLs, and last error diagnostics. Essential for verifying repository synchronization between local self-hosted instances and upstream GitLab instances or remote Git hosts. | No |
| Force an immediate push mirror synchronization for a designated project remote mirror. Use when code has been committed locally and immediate upstream replication is required without waiting for the scheduled background sync interval. | Yes |
| List available GitLab CI/CD runners (instance, group, or project-level), detailing their online status, active/paused state, and executor types. Use to diagnose CI pipeline execution delays, runner connectivity, or missing executor tags. | No |
| Retrieve comprehensive details and health status for a specific CI/CD runner, including IP address, architecture, runner version, tags, and last contacted timestamp. Use to troubleshoot stuck jobs or unresponsive self-hosted runners. | No |
| List configured project webhooks and their subscribed triggers (push, merge requests, issues, pipeline events). Use to audit integration webhooks and verify CI/CD automation hook registrations. | No |
repositories — 10 actions)Action | Description | Mutating? |
| Search for GitLab projects and repositories across the instance or scoped to a specific group namespace (recommended to reduce instance load). Capped at 100 per page. If project_id or path_with_namespace is already known, look up directly via 'get_project'. | No |
| Retrieve comprehensive metadata for a specific GitLab project, including default branch, repository statistics, visibility, and topic tags. Use to inspect repository settings or verify project access. Do NOT use to inspect directory trees or source code; use 'get_file_contents' instead. | No |
| Create a new GitLab project/repository under your personal namespace or a designated group. Use when provisioning new codebases or initializing repositories. Side effect: creates a new GitLab project immediately. Do NOT use to duplicate existing projects; use 'fork_repository' instead. | Yes |
| Update mutable project settings including display name, description, default branch, visibility level, and topics. Use to modify repository configurations or administrative details. Side effect: alters project settings immediately. Do NOT use to commit code changes; use 'create_or_update_file' or 'push_files'. | Yes |
| Permanently delete a GitLab project and all its repository files, issues, merge requests, and CI/CD pipelines. Use solely for project decommissioning. Side effect: DESTRUCTIVE and irreversible. Requires explicit safety confirmation via confirm_project_name. | Yes |
| Read the raw content of a specific file or directory tree from a repository at a designated branch, tag, or commit ref. Use when inspecting current repository source code or configs. Do NOT use for reviewing diffs between branches (use 'get_merge_request_changes') or viewing commit diffs (use 'get_commit'). | No |
| Create a new file or update the content of an existing file in a repository with a Git commit. Use for single-file changes or documentation updates. Side effect: creates an immediate Git commit on the remote branch. Do NOT use when updating multiple files together; use 'push_files' instead for atomic multi-file commits. | Yes |
| Atomically commit multiple file additions, modifications, or deletions to a target branch in a single Git commit. Use for multi-file refactors, features, or project scaffolding. Side effect: creates an atomic multi-action Git commit on the remote branch. Use instead of calling 'create_or_update_file' in a loop. | Yes |
| Atomically commit multiple file additions, modifications, or updates to a target branch in a single Git commit using GitLab Commits API. Use for multi-file refactors, features, or project scaffolding without local git cloning. Side effect: creates an atomic multi-action Git commit on the remote branch. | Yes |
| Fork an existing GitLab project into a designated user namespace or group. Use when contributing to upstream projects or establishing an independent fork. Side effect: provisions a new repository linked to the upstream source. Do NOT use to create fresh empty projects; use 'create_repository' instead. | Yes |
branches — 7 actions)Action | Description | Mutating? |
| List repository branches with latest commit summaries, default branch indicators, and protected status. Use to discover active development branches or check branch existence. Do NOT use to inspect commit diffs (use 'get_commit') or list tags (use 'list_tags'). | No |
| Retrieve comprehensive details for a specific Git branch, including latest commit SHA, author info, and branch protection rules. Use to verify commit alignment before creating merge requests. Do NOT use to inspect file contents directly; use 'get_file_contents' instead. | No |
| Create a new Git branch starting from an existing branch, tag, or commit SHA. Use to initialize feature branches, bugfixes, or release branches. Side effect: creates a new branch pointer on the remote repository. Do NOT use to create new repositories; use 'create_repository' instead. | Yes |
| Delete an existing Git branch from a project repository. Use to clean up merged or obsolete feature branches. Side effect: DESTRUCTIVE. Accidental deletion of the project's default branch is actively blocked for safety. Do NOT use to delete tags; use Git tag management instead. | Yes |
| List protected branch rules configured in a GitLab project, showing push/merge access levels, force-push permission, and code owner approval requirements. Use to audit branch governance and merge restrictions. | No |
| Configure branch protection rules for a branch or wildcard pattern (e.g. 'main', 'release/*'). Controls push access levels, merge access levels, force push permission, and code owner approval. | Yes |
| Remove branch protection rules from a specified branch or wildcard pattern. Side effect: DESTRUCTIVE. Removes push and merge access restrictions from the target branch. | Yes |
commits — 2 actions)Action | Description | Mutating? |
| List chronological commit history for a project, branch, or specific file path with author metadata and commit messages. Filter upstream by ref_name, author, path, and date range. To inspect exact code changes of a specific commit SHA, use 'get_commit' instead. | No |
| Retrieve comprehensive details for a specific Git commit SHA, including author info, statistics, modified files, and selective unified file diffs. Use to inspect exact code changes made in a commit. Supports file_path filtering and line limits to prevent context exhaustion on large commits. | No |
pipelines — 10 actions)Action | Description | Mutating? |
| List CI/CD pipelines filtered by branch, tag, status ('running', 'success', 'failed', 'canceled'), or commit SHA with token-efficient status summaries. Use to check deployment status, monitor test suite health, or verify build triggers. Do NOT use to inspect specific job logs; use 'get_job_trace' instead. | No |
| Retrieve comprehensive details for a specific CI/CD pipeline by numeric ID, including execution status, duration, queued duration, and associated commit info. Use to evaluate pipeline health or check if all stages completed. Do NOT use to inspect individual job failures; use 'list_pipeline_jobs' or 'get_job_trace' instead. | No |
| Manually trigger and run a new CI/CD pipeline execution for a specific branch or tag with optional custom pipeline variables. Use to kick off tests, builds, or deployments on demand. Side effect: initiates immediate job execution on GitLab runners. Do NOT use to inspect running jobs; use 'list_pipeline_jobs' instead. | Yes |
| Cancel all running and pending jobs in an active CI/CD pipeline run by numeric pipeline_id. Side effect: terminates active runner jobs for this pipeline immediately. | Yes |
| Retry all failed or canceled jobs in an existing CI/CD pipeline run by numeric pipeline_id. Side effect: re-queues failed/canceled jobs on GitLab runners immediately. | Yes |
| List all execution jobs (build, test, lint, deploy) and their current status within a specific pipeline. Use to identify which specific stage or job failed in a pipeline run. Do NOT use to download job output logs; use 'get_job_trace' instead once the failed job ID is known. | No |
| Retrieve comprehensive details about a specific CI/CD job, including duration, runner tags, failure reasons, and available artifact archives. Use when diagnosing why a runner job stalled or failed. Do NOT use to stream terminal logs; use 'get_job_trace' instead. | No |
| Retrieve the raw terminal console output log for a specific CI/CD job with configurable tailing (tail_lines). Use to inspect compilation errors, stack traces, and test assertion failures without overflowing context. Do NOT use to inspect structured JUnit test suites; use 'get_pipeline_test_report' instead. | No |
| Download and read the text content of a specific file from a completed job's build artifacts zip archive (e.g. coverage reports, build manifests, test outputs). Use to inspect generated artifacts without downloading the full archive. Do NOT use for repository files; use 'get_file_contents' instead. | No |
| Retrieve the structured JUnit test summary report for a pipeline run, including total test counts, passed/failed test cases, execution duration, and failure stack traces. Use to diagnose automated test failures across test suites. Do NOT use for raw console output; use 'get_job_trace' instead. | No |
merge-requests — 12 actions)Action | Description | Mutating? |
| List merge requests filtered by state ('opened', 'closed', 'merged', 'all'), source/target branches, milestone, labels, author, assignee, reviewer, or search text pushed directly upstream to GitLab's indexed database. Architectural Best Practice: For known MRs, always prefer 'get_merge_request' with exact merge_request_iid rather than broad listing. | No |
| Retrieve comprehensive details for a specific merge request by IID (!), including status, mergeability, approval state, branch names, diff head SHA, and description. Use to evaluate review state or prepare for merging. Do NOT use to inspect file diffs; use 'get_merge_request_changes' instead. | No |
| Create a new merge request proposing changes from a source branch into a target branch. Supports setting title, markdown description, assignees, reviewers, milestone, and target branch removal options. Side effect: creates a new GitLab MR immediately. Do NOT use to post review comments; use 'create_diff_discussion' instead. | Yes |
| Update an existing merge request's title, description, target branch, milestone, labels, assignees, or state ('close' or 'reopen'). Use to update MR details or close obsolete requests. Side effect: alters MR configuration immediately. Do NOT use to merge the MR; use 'accept_merge_request' instead. | Yes |
| Inspect unified code diffs and modified files for an MR. Features token-saving summaries (summary_only), file path filtering, lockfile pruning, and automatic diff refs (base_sha, start_sha, head_sha) needed for inline comments. Use for AI code review analysis. | No |
| List inline code review discussions, comment threads, and resolution statuses on a merge request. Supports filtering for unresolved review comments (unresolved_only: true). Use when reviewing outstanding code comments or verifying review feedback. Do NOT use for general project issue comments; use 'list_issue_notes' instead. | No |
| Start a new inline code review discussion thread anchored to a specific file and line number in an MR diff. Automatically resolves the required base_sha, start_sha, and head_sha from the MR if omitted. Use during code reviews to leave actionable inline feedback. Side effect: posts a public review thread immediately. | Yes |
| Post a reply comment into an existing code review discussion thread on a merge request. Use to answer review feedback or confirm code fixes. Side effect: appends a reply note to the discussion thread immediately. Do NOT use to resolve the discussion; use 'resolve_merge_request_discussion' instead. | Yes |
| Edit or update the text of an existing review comment in an MR discussion thread. Use when correcting review remarks or updating code suggestions. Side effect: modifies the comment text immediately. Do NOT use to post new comments; use 'reply_merge_request_discussion' or 'create_diff_discussion' instead. | Yes |
| Resolve or unresolve an entire code review discussion thread on a merge request. Use when verification has confirmed that review feedback has been addressed. Side effect: updates the review thread resolution status immediately. | Yes |
| Merge an approved merge request into its target branch. Supports squash commits, custom merge commit messages, and deleting the source branch upon merge. Side effect: merges branches and triggers downstream CI/CD deployment pipelines immediately. Do NOT use if tests are failing or approvals are pending. | Yes |
| Post a top-level general comment or review summary note on a merge request. Use for overall review summaries, LGTMs, or test execution reports. Side effect: posts a general note to the MR immediately. Do NOT use for line-specific diff review feedback; use 'create_diff_discussion' instead. | Yes |
issues — 8 actions)Action | Description | Mutating? |
| List and filter project issues by state ('opened', 'closed', 'all'), milestone, labels, author, assignee, or keyword search pushed directly upstream to GitLab's indexed database. Architectural Best Practice: For known issues, always prefer 'get_issue' with exact issue_iid rather than broad listing. | No |
| Retrieve comprehensive details for a specific issue by its project-scoped IID (#), including description, assignees, labels, milestone, and issue status. Use to review issue requirements or track resolution. Do NOT use to list comments on the issue; use 'list_issue_notes' instead. | No |
| Create a new issue with a title, markdown description, milestone (by title or ID), labels, assignees, and optional due date. Use to report bugs, track user stories, or plan tasks. Side effect: creates a new GitLab issue immediately. Do NOT use to comment on existing issues; use 'create_issue_note' instead. | Yes |
| Update an existing issue's title, description, state ('close' or 'reopen'), milestone, labels, or assignees. Use to transition issue lifecycle or update task status. Side effect: alters issue state immediately. Do NOT use to post progress comments; use 'create_issue_note' instead. | Yes |
| List the chronological discussion notes, user comments, and activity audit log for a specific issue by IID. Use to review problem discussion, past comments, or implementation progress. Do NOT use for merge request discussions; use 'list_merge_request_discussions' instead. | No |
| Post a new markdown comment, progress update, or verification note to an existing issue. Use to communicate findings, document test results, or ask questions on a task. Side effect: posts a public comment to the issue thread immediately. | Yes |
| List issue dependency links ('relates_to', 'blocks', 'is_blocked_by') associated with a specific issue. Use when analyzing task dependencies or release blockers. Do NOT use to inspect issue discussion notes; use 'list_issue_notes' instead. | No |
| Create a dependency or relationship link between two issues ('relates_to', 'blocks', 'is_blocked_by'), across the same project or across different projects. Use to track blocker relationships or connected bug reports. Side effect: creates a bi-directional issue relationship immediately. | Yes |
milestones — 6 actions)Action | Description | Mutating? |
| List project and ancestor group milestones filtered by state ('active', 'closed', 'all') with start dates, due dates, and progress. Use to track sprint goals, release targets, or project roadmaps. Do NOT use to inspect individual issue lists inside a milestone; use 'list_issues' with a milestone filter instead. | No |
| Retrieve comprehensive details for a specific project milestone by numeric ID, including description, dates, and state. Use when validating target milestone dates or checking milestone progress. Do NOT use to list project milestones; use 'list_milestones' instead. | No |
| Create a new project milestone with a title, description, start date, and due date. Use to plan a release version, sprint, or delivery roadmap. Side effect: creates a new project milestone immediately. Do NOT use to create releases; use 'create_release' instead. | Yes |
| Update an existing milestone's title, description, due date, start date, or lifecycle state ('activate' or 'close'). Use to adjust release schedules or complete sprints. Side effect: alters milestone metadata immediately. | Yes |
| List labels available within a project (including inherited ancestor group labels) with colors and descriptions. Use to discover valid taxonomy labels before categorizing issues or merge requests. Do NOT use to create new labels; use 'create_label' instead. | No |
| Create a new label with a name, hexadecimal color code, and description in a project. Use when establishing project workflow tags, priority markers, or component categories. Side effect: creates a new project label immediately. | Yes |
releases — 5 actions)Action | Description | Mutating? |
| List published GitLab releases, version tags, changelog descriptions, and linked assets. Use when checking released versions or reviewing release history. Do NOT use to inspect raw git tags without release notes; use 'list_tags' instead. | No |
| Retrieve comprehensive details for a published release by tag name, including markdown release notes, author, and downloadable asset links. Use to view full release notes or changelogs. Do NOT use to inspect milestone goals; use 'get_milestone' instead. | No |
| Publish a formal GitLab release associated with a git tag, including title, markdown changelog notes, and linked milestone titles. If the tag does not exist, ref is required to create it. Side effect: creates a formal public release entry. Do NOT use to create bare tags; use 'create_tag' instead. | Yes |
| List Git tags in the repository with commit target SHAs, release links, and annotation messages. Use to check if a specific release tag already exists before tagging. Do NOT use to view release notes; use 'list_releases' instead. | No |
| Create an annotated or lightweight Git tag pointing to a specific branch or commit SHA. Use to mark release points or version milestones in Git history. Side effect: creates a new Git tag on the remote repository immediately. Do NOT use to publish full release notes; use 'create_release' instead. | Yes |
members — 5 actions)Action | Description | Mutating? |
| List project members and collaborators with their assigned access levels, roles, and membership expiration dates. Supports filtering and including inherited group members. Use to audit project permissions or check collaborator access before assigning tasks. Do NOT use to inspect global user profiles; use 'get_current_user' instead. | No |
| Retrieve membership details, access level, and permissions for a specific user in a project by numeric ID or username. Use to verify whether a collaborator has Developer or Maintainer rights before triggering protected actions. Do NOT use to search all members; use 'list_project_members' instead. | No |
| Grant project access to a user with a specific role ('guest', 'reporter', 'developer', 'maintainer', 'owner') and optional expiration date. Resolves usernames automatically. Side effect: grants repository permissions immediately. Do NOT use to update existing memberships; use 'update_project_member' instead. | Yes |
| Change an existing collaborator's access level role or expiration date within a project. Resolves usernames automatically. Side effect: alters project access control immediately. Do NOT use to add new members; use 'add_project_member' instead. | Yes |
| Revoke a collaborator's access to a project repository and its associated resources. Side effect: DESTRUCTIVE for user access; immediately removes repository permissions. Do NOT use to adjust access levels; use 'update_project_member' instead. | Yes |
variables — 5 actions)Action | Description | Mutating? |
| List all CI/CD pipeline variables configured for a project, including keys, variable types ('env_var' or 'file'), protected/masked flags, and environment scopes. Use to verify secret and configuration presence before running build/deploy pipelines. Do NOT use to fetch secret values; use 'get_project_variable' instead. | No |
| Retrieve comprehensive details and current value of a specific CI/CD variable by key name. Use when debugging pipeline environment failures or checking secret values. Do NOT use to list all configured variables; use 'list_project_variables' instead. | No |
| Create a new CI/CD pipeline variable ('env_var' or 'file') with protected, masked, and environment scope settings. Use when configuring build secrets, tokens, or environment configs. Side effect: exposes the variable to CI/CD pipeline jobs immediately. Do NOT use to update existing variables; use 'update_project_variable' instead. | Yes |
| Update the value, masking status, protection status, or environment scope of an existing CI/CD variable. Use when rotating secrets or updating configuration values. Side effect: alters the pipeline execution environment immediately. Do NOT use to create new variables; use 'create_project_variable' instead. | Yes |
| Permanently delete a CI/CD pipeline variable from a project by key. Use when revoking expired credentials or cleaning up obsolete configuration. Side effect: DESTRUCTIVE; subsequent pipeline runs will no longer have access to this variable. | Yes |
wikis — 4 actions)Action | Description | Mutating? |
| List all wiki documentation pages in a project with page slugs, titles, and formatting types. Use to discover available project documentation or guides. Do NOT use to read complete page contents; use 'get_wiki' instead. | No |
| Retrieve wiki documentation content by page slug, with token-saving options including structured Table of Contents (toc_only: true) or targeting a specific chapter/heading section (section: 'Heading'). Use to consult project architectural guides without context blowout. Do NOT use for repository files; use 'get_file_contents' instead. | No |
| Create a new wiki documentation page in a project with markdown content and formatting options. Use to document setup procedures, architecture, or design runbooks. Side effect: creates a new project wiki page immediately. Do NOT use to update existing pages; use 'update_wiki' instead. | Yes |
| Update the markdown content or title of an existing project wiki page by slug. Use to update living project documentation, runbooks, or specifications. Side effect: alters the wiki page content immediately. Do NOT use to create new wiki pages; use 'create_wiki' instead. | Yes |
snippets — 4 actions)Action | Description | Mutating? |
| List code snippets published in a GitLab project with author details, file names, and visibility levels ('private', 'internal', 'public'). Use to discover utility scripts, SQL queries, or configuration templates stored in project snippets. Do NOT use to inspect raw snippet code; use 'get_snippet' instead. | No |
| Retrieve comprehensive details and raw text content for a specific code snippet by numeric ID. Use to inspect code scripts, patches, or configuration snippets. Do NOT use for repository files; use 'get_file_contents' instead. | No |
| Create a new code or text snippet in a project with a title, file name, markdown description, and visibility setting. Use to share debug scripts, one-off patches, or configuration snippets. Side effect: creates a new GitLab snippet immediately. Do NOT use to commit files to git repositories; use 'create_or_update_file' instead. | Yes |
| Update the code content, file name, title, description, or visibility of an existing project snippet by numeric ID. Use to maintain snippet code or adjust access. Side effect: alters the snippet immediately. Do NOT use to create new snippets; use 'create_snippet' instead. | Yes |
user — 6 actions)Action | Description | Mutating? |
| Retrieve identity and profile details of the authenticated GitLab account (username, numeric ID, name, email, admin flag). Use to verify token validity, check active permissions, or discover your own username for assignment. Do NOT use to query other users' profiles; use 'list_project_members' instead. | No |
| List GitLab groups and parent organizations where the authenticated user is an active member or owner with access roles. Use to discover namespace paths available for project creation or access audits. Do NOT use to inspect project lists directly; use 'list_group_projects' instead. | No |
| Create a new GitLab group or nested subgroup (using parent_id). Use to organize projects, manage team namespaces, and establish shared permissions. Side effect: creates a new group on GitLab immediately. | Yes |
| Retrieve comprehensive details for a specific GitLab group or namespace by its numeric ID or full path (e.g. 'buggycode'). Use when checking group-level visibility, description, or parent group hierarchy. Do NOT use to list projects in the group; use 'list_group_projects' instead. | No |
| List all repositories and projects belonging to a specific GitLab group or organization with pagination and search. Supports include_subgroups (default: true). Use to discover projects within a team or enterprise namespace. Do NOT use for cross-instance project search; use 'search_repositories' instead. | No |
| List GitLab projects where the authenticated user is a direct member, owner, or starred contributor with role summaries. Use to discover personal repositories or starred codebases. Do NOT use for generic text searches across public projects; use 'search_repositories' instead. | No |
Reproducible deterministic benchmark (node test/benchmark-test.js & node test/catalog-execution-test.js) measured against canonical GitLab REST API v4 payloads (test/fixtures/gitlab-api-v4-fixtures.js, token count = Math.ceil(utf8Bytes / 4)):
Operation | Raw GitLab API v4 |
|
| Token Reduction (MD) |
System Prompt Tax (5 tools vs 90 actions) | 27,681 tokens | — | 1,292 tokens | 95.3% savings |
| 971 tokens | 144 tokens | 124 tokens | 87.2% savings |
| 6,595 tokens | 1,906 tokens | 460 tokens | 93.0% savings |
| 6,377 tokens | 1,058 tokens | 423 tokens | 93.4% savings |
| 880 tokens | 543 tokens | 212 tokens | 75.9% savings |
| 279 tokens | 201 tokens | 160 tokens | 42.7% savings |
| 3,612 tokens | 156 tokens | 141 tokens | 96.1% savings |
Measured across all 90 handlers via node test/catalog-execution-test.js:
Domain | Actions | Raw GitLab v4 Tokens | Projected JSON | Rendered Markdown | Token Savings (MD) |
repositories | 10 | 8,966 tokens | 1,361 tokens | 728 tokens | 91.9% |
branches | 7 | 6,797 tokens | 326 tokens | 245 tokens | 96.4% |
commits | 2 | 1,942 tokens | 179 tokens | 125 tokens | 93.6% |
members | 5 | 4,855 tokens | 197 tokens | 174 tokens | 96.4% |
variables | 5 | 4,855 tokens | 200 tokens | 191 tokens | 96.1% |
issues | 8 | 52,760 tokens | 6,454 tokens | 1,419 tokens | 97.3% |
milestones | 6 | 39,570 tokens | 387 tokens | 217 tokens | 99.5% |
pipelines | 10 | 65,950 tokens | 1,304 tokens | 726 tokens | 98.9% |
releases | 5 | 32,975 tokens | 185 tokens | 193 tokens | 99.4% |
merge-requests | 12 | 79,140 tokens | 1,498 tokens | 867 tokens | 98.9% |
wikis | 4 | 26,380 tokens | 65 tokens | 69 tokens | 99.7% |
snippets | 4 | 26,380 tokens | 465 tokens | 453 tokens | 98.3% |
user | 6 | 39,570 tokens | 249 tokens | 251 tokens | 99.4% |
enterprise | 6 | 39,570 tokens | 245 tokens | 302 tokens | 99.2% |
TOTAL (All 90 Actions) | 90 | 429,710 tokens | 13,115 tokens | 5,960 tokens | 98.6% |
Smart Diff & Lockfile Truncation: Commit diffs (get_commit) and MR changes (get_merge_request_changes) automatically collapse dependency lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, go.sum, Cargo.lock, *.min.js) via ignore_lockfiles: true by default, saving 1,000–3,000 tokens per review. Pass ignore_lockfiles: false if full lockfile diffs are required.
Conservative Default Pagination: All list actions default to per_page: 10 (max: 100), eliminating token waste from loading 20–50 items when only recent entries are needed.
Default High-Density Markdown Format: Discovery (gitlab_find_actions), execution (gitlab_execute_action), project info (get_project), file inspection (get_file_contents), and commit inspection (get_commit) default to format: "markdown", yielding 75%–96% token reductions for structured metadata.
Recursive Output Projection Filter (projectOutput): Strips GitLab REST API v4 noise metadata keys (_links, avatar_url, references, time_stats, task_completion_status, commands_changes, user_notes_count, merge_requests_count, upvotes, downvotes, subscribed, has_tasks, service_desk_reply_to, moved_to_id, container_expiration_policy, permissions, and null/empty fields) before payloads reach LLM context.
Upstream indexed filtering & strict pagination caps (state, labels, milestone, author_id, assignee_id)
Client error resilience (401 probe disambiguation, 403 insufficient scope, 429 rate limit backoff, 201 ghost write guard)
Hardened output projection with recursion depth guard (maxDepth = 32) and empty collection preservation
Nested subgroup hierarchy management (create_group with parent_id)
Smart CI/CD failure log extraction & ANSI sequence stripping in get_job_trace (strip_ansi, smart_failure)
Outline-first code symbol extraction & line range slicing in get_file_contents (outline_only, start_line, end_line)
Pre-flight mergeability & conflict verification (get_mergeability)
Token scope self-auditing & permission pre-flight
Standardized collection _summary headers to facilitate multi-turn history pruning in LiteLLM / Eigent agent orchestration
Remote Transports: Streamable SSE and HTTP remote server modes
Scoped GraphQL query engine for relational deep inspections
DevSecOps vulnerability & secret scanning alert queries
Scoped & rate-guarded code search within project repositories
This project incorporates architectural concepts, schemas, and patterns from:
@modelcontextprotocol/server-gitlab (MIT License) — Copyright (c) 2024 Anthropic, PBC / GitLab, PBC. Baseline repository and file schema patterns.
@modelcontextprotocol/sdk (MIT License) — Copyright (c) Anthropic, PBC.
zod (MIT License) — Colin McDonnell.
GitLab REST API v4 — GitLab, PBC.
jmrplens/gitlab-mcp-server — Dynamic action discovery and meta-dispatcher pattern concepts.
Architectural patterns evaluated from Vijay-Duke/mcp-gitlab and zereight/gitlab-mcp.
See NOTICE for complete third-party attribution details.
This project is licensed under the MIT License — Copyright (c) 2026 sumirati@buggycode.net.
Retrieve comprehensive details for a specific Git commit SHA, including author info, statistics, modified files, and selective unified file diffs. Use to inspect exact code changes made in a commit. Supports file_path filtering and line limits to prevent context exhaustion on large commits.
| Name | Required | Description | Default |
|---|---|---|---|
| sha | Yes | Commit SHA or short commit hash to inspect | |
| format | Yes | Output format: 'markdown' (default) or 'json' | markdown |
| file_path | No | Filter diffs to only this specific file (prevents token blowout on large multi-file commits) | |
| with_diff | Yes | If true, includes file diffs for the commit | |
| project_id | Yes | Project numeric ID (e.g. 31) or namespace path (e.g. 'group/project-name'). URL-encoding is handled automatically. | |
| max_diff_lines | Yes | Maximum lines of diff text to return per file (default: 500) | |
| ignore_lockfiles | Yes | If true, automatically collapses diffs for lockfiles and minified assets (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent profile, so the description is free to add operational context instead: the warnings about context/token exhaustion on large commits and the mitigations (file_path filtering, line limits, lockfile collapsing) are genuine behavioral value. It does not mention auth requirements or pagination/truncation behavior in the response, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose plus return contents front-loaded, then usage, then the safety/mitigation constraint. No filler and nothing buried at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter read tool with no output schema and full annotation coverage, the description covers the key risks (large diffs, token blowout) an agent needs before calling. It omits only minor operational detail such as result size ceilings or what happens when the SHA is not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (sha, format, file_path, with_diff, max_diff_lines, ignore_lockfiles) is already documented in the schema. The description restates the file_path filter and line-limit behavior but adds no syntax or format detail beyond what the schema says. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Retrieve comprehensive details for a specific Git commit SHA') and enumerates what is returned (author info, statistics, modified files, unified diffs). The sibling tools (get_file_contents, get_project, gitlab_find_actions) occupy clearly different resources, though the description never names them to reinforce the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use to inspect exact code changes made in a commit' gives a clear triggering context. It does not state when-not to use it or point to an alternative (e.g. get_file_contents for file-level history), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the raw content of a specific file or directory tree from a repository at a designated branch, tag, or commit ref. Use when inspecting current repository source code or configs. Do NOT use for reviewing diffs between branches (use 'get_merge_request_changes') or viewing commit diffs (use 'get_commit').
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch name, tag, or commit SHA (default: default branch / HEAD) | |
| end_line | No | Optional 1-based end line to slice content | |
| file_path | Yes | Path to the file or directory in repo (e.g. 'pom.xml', 'docs/README.md', or 'src' for directory tree) | |
| project_id | Yes | Project numeric ID (e.g. 31) or namespace path (e.g. 'group/project-name'). URL-encoding is handled automatically. | |
| start_line | No | Optional 1-based start line to slice content | |
| outline_only | Yes | When true, extract and return only high-level symbol declarations (classes, functions, interfaces, methods, types) with their line numbers instead of full content (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond that: it can read either a file or a whole directory tree, and it operates at an arbitrary ref. It does not mention output size limits or truncation behavior for large files, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler, with the core purpose front-loaded before the use and anti-use guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally hint at return shape, but it does convey that content may be a directory tree or symbol outline. Combined with fully documented params and rich annotations, the definition is nearly complete; only large-file/truncation behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including ref, file_path, start_line/end_line, and outline_only is already documented in the schema. The description mentions ref types and directory trees but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('raw content of a specific file or directory tree from a repository') with the scope qualifier of ref (branch, tag, or commit). It explicitly names the sibling tools it is not (get_merge_request_changes, get_commit), so an agent can differentiate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case ('inspecting current repository source code or configs') plus two negative exclusions that name the alternative tools for diff review and commit diffs. This is textbook when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive metadata for a specific GitLab project, including default branch, repository statistics, visibility, and topic tags. Use to inspect repository settings or verify project access. Do NOT use to inspect directory trees or source code; use 'get_file_contents' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Output format: 'markdown' (default) or 'json' | markdown |
| project_id | Yes | Project numeric ID (e.g. 31) or namespace path (e.g. 'group/project-name'). URL-encoding is handled automatically. | |
| statistics | Yes | Include project repository and storage statistics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the return content, which is useful, but says nothing about authentication scope, rate limits, or behavior on a missing/inaccessible project. With annotations carrying the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first states scope and payload, the second routes usage and the exclusion. Everything is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by naming the metadata returned (default branch, statistics, visibility, topics). Combined with the 100%-covered input schema and full annotations, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so project_id, statistics, and format are all documented in the schema itself, including the ID/path format and the enum default. The description adds no parameter-level detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (retrieve) and resource (GitLab project metadata), then enumerates the concrete payload (default branch, repository statistics, visibility, topic tags). This clearly separates it from siblings like get_file_contents and get_commit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives when to use ('inspect repository settings or verify project access') and when not to use ('Do NOT use to inspect directory trees or source code'), naming the alternative tool 'get_file_contents'. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any discovered GitLab platform action with input validation and token-optimized response projection. Dispatches directly to the corresponding API endpoint while enforcing read-only safety restrictions.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The exact GitLab action name to execute (e.g. 'create_merge_request', 'list_pipelines', 'trigger_push_mirror_sync') | |
| format | Yes | Output format: 'markdown' (default, token-optimized compact table/text for LLM) or 'json' (structured JSON) | markdown |
| params | No | Alias for parameters (for cross-client compatibility) | |
| parameters | No | Key-value parameters for the designated action (as discovered from gitlab_find_actions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false (the tool can perform write actions, and the schema examples include create_merge_request and trigger_push_mirror_sync), yet the description claims it operates 'while enforcing read-only safety restrictions.' A tool that actually enforced read-only restrictions could not dispatch to a create endpoint, so the description directly contradicts the declared read/write profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the dispatch purpose followed by the response/safety claim; there is no filler. Slightly jargon-heavy ('token-optimized response projection') but still tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic dispatcher taking a free-form action string plus a nested parameter object, the description omits how callers learn valid action names (the discovery dependency) and gives no return-shape context beyond 'projection.' The misleading read-only claim also leaves the safety contract unclear, so it is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so action, format, params, and parameters are already documented in the schema; the description adds nothing about parameter shape or the params/parameters aliasing. Per the rule, a fully covered schema yields a baseline of 3 even with no added param detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Execute any discovered GitLab platform action') and frames itself as a generic dispatcher, which distinguishes it from concrete siblings like get_file_contents and get_project. It does not explicitly name those siblings or clarify when to prefer them over this catch-all dispatcher, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'discovered' plus the schema note ('as discovered from gitlab_find_actions') implies a prerequisite step, so usage is implied but never stated as when/when-not. No explicit guidance about preferring dedicated get_* tools over this dispatcher, so it is only minimally viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and discover available GitLab operations on-demand across the entire platform. Returns matching action names, purpose descriptions, and parameter schemas for use with 'gitlab_execute_action'. Keeps prompt context minimal (<500 tokens) while retaining 100% coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Page number for paginated action results (default: 1) | |
| query | No | Search keywords to find operations (e.g. 'merge request', 'pipeline', 'runner', 'mirror', 'release', 'branch', 'job trace') | |
| domain | No | Optional domain to scope the search | |
| format | Yes | Output format: 'markdown' (default, compact human/LLM-readable text table) or 'json' (structured object with parameter schemas) | markdown |
| per_page | Yes | Number of actions per page (default: 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restatement. The description earns credit for disclosing output traits beyond the annotations: it returns action names, purpose descriptions, and parameter schemas, and it bounds prompt cost ('<500 tokens'). It does not discuss pagination or empty-result behavior, keeping it at a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool does and followed by return contents and the context-budget claim. Every sentence is relevant, though the '<500 tokens while retaining 100% coverage' phrasing leans slightly promotional rather than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description carries the burden of describing returns, and it does: action names, purpose descriptions, and parameter schemas, with the format parameter governing structure. Combined with the annotation coverage and fully documented input schema, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with enums and defaults documented for query, domain, format, page, and per_page, so the baseline is 3. The description adds only the general notion that results carry parameter schemas; it contributes no syntax, matching, or scoping detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (search/discover) and a specific resource (available GitLab operations across the platform), and explicitly frames itself as the discovery counterpart to the sibling gitlab_execute_action. An agent can distinguish this lookup tool from the execution tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for use with gitlab_execute_action' and 'on-demand' clearly implies the intended workflow: discover an action's name and schema here, then execute it there. There is no explicit when-not condition or named alternative search path, so it falls short of a 5, but the routing context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.2.0get_file_contents1 field changedInput schema / properties / file_path / descriptionPrevious value: -"Path to the file or directory in repo (e.g. 'pom.xml' or 'docs/README.md')"New value: +"Path to the file or directory in repo (e.g. 'pom.xml', 'docs/README.md', or 'src' for directory tree)"v3.1.0accept_merge_requestadd_project_membercreate_branchcreate_diff_discussioncreate_issuecreate_issue_linkcreate_issue_notecreate_labelcreate_merge_requestcreate_merge_request_notecreate_milestonecreate_or_update_filecreate_pipelinecreate_project_variablecreate_releasecreate_repositorycreate_snippetcreate_tagcreate_wikidelete_branchdelete_projectdelete_project_variablefork_repositoryget_branchget_commit3 fields changedInput schema / properties / formatAdded value: +{
+ "default": "markdown",
+ "description": "Output format: 'markdown' (default) or 'json'",
+ "enum": [
+ "json",
+ "markdown"
+ ],
+ "type": "string"
+}Input schema / properties / ignore_lockfilesAdded value: +{
+ "default": true,
+ "description": "If true, automatically collapses diffs for lockfiles and minified assets (default: true)",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "project_id",
- "sha",
- "with_diff",
- "max_diff_lines"
-]New value: +[
+ "project_id",
+ "sha",
+ "with_diff",
+ "max_diff_lines",
+ "ignore_lockfiles",
+ "format"
+]get_current_userget_file_contents4 fields changedInput schema / properties / end_lineAdded value: +{
+ "description": "Optional 1-based end line to slice content",
+ "type": "number"
+}Input schema / properties / outline_onlyAdded value: +{
+ "default": false,
+ "description": "When true, extract and return only high-level symbol declarations (classes, functions, interfaces, methods, types) with their line numbers instead of full content (default: false)",
+ "type": "boolean"
+}Input schema / properties / start_lineAdded value: +{
+ "description": "Optional 1-based start line to slice content",
+ "type": "number"
+}Input schema / requiredPrevious value: -[
- "project_id",
- "file_path"
-]New value: +[
+ "project_id",
+ "file_path",
+ "outline_only"
+]get_groupget_issueget_jobget_job_artifact_fileget_job_traceget_merge_requestget_merge_request_changesget_milestoneget_pipelineget_pipeline_test_reportget_project2 fields changedInput schema / properties / formatAdded value: +{
+ "default": "markdown",
+ "description": "Output format: 'markdown' (default) or 'json'",
+ "enum": [
+ "json",
+ "markdown"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "project_id",
- "statistics"
-]New value: +[
+ "project_id",
+ "statistics",
+ "format"
+]get_project_memberget_project_variableget_releaseget_snippetget_wikigitlab_execute_actiongitlab_find_actionslist_brancheslist_commitslist_group_projectslist_issue_linkslist_issue_noteslist_issueslist_labelslist_merge_request_discussionslist_merge_requestslist_milestoneslist_my_groupslist_my_projectslist_pipeline_jobslist_pipelineslist_project_memberslist_project_variableslist_releaseslist_snippetslist_tagslist_wikispush_filesremove_project_memberreply_merge_request_discussionresolve_merge_request_discussionsearch_repositoriesupdate_issueupdate_merge_requestupdate_merge_request_discussion_noteupdate_milestoneupdate_projectupdate_project_memberupdate_project_variableupdate_snippetupdate_wikiv2.0.0accept_merge_requestadd_project_membercreate_branchcreate_diff_discussioncreate_issuecreate_issue_linkcreate_issue_notecreate_labelcreate_merge_requestcreate_merge_request_notecreate_milestonecreate_or_update_filecreate_pipelinecreate_project_variablecreate_releasecreate_repositorycreate_snippetcreate_tagcreate_wikidelete_branchdelete_projectdelete_project_variablefork_repositoryget_branchget_commitget_current_userget_file_contentsget_groupget_issueget_jobget_job_artifact_fileget_job_traceget_merge_requestget_merge_request_changesget_milestoneget_pipelineget_pipeline_test_reportget_projectget_project_memberget_project_variableget_releaseget_snippetget_wikilist_brancheslist_commitslist_group_projectslist_issue_linkslist_issue_noteslist_issueslist_labelslist_merge_request_discussionslist_merge_requestslist_milestoneslist_my_groupslist_my_projectslist_pipeline_jobslist_pipelineslist_project_memberslist_project_variableslist_releaseslist_snippetslist_tagslist_wikispush_filesremove_project_memberreply_merge_request_discussionresolve_merge_request_discussionsearch_repositoriesupdate_issueupdate_merge_requestupdate_merge_request_discussion_noteupdate_milestoneupdate_projectupdate_project_memberupdate_project_variableupdate_snippetupdate_wikiScored across 5 tools
The three get_* tools target distinct resources (file, project, commit) with clear exclusions. However, gitlab_execute_action can perform the same operations as the specific getters, creating overlap; the find/execute pair is distinct from the getters but the generic executor's broad scope can cause indecision.
Three tools use snake_case verb_noun without a prefix; two use a gitlab_ prefix with verb_noun. The core convention is consistent, but the prefix split and find_actions/execute_action (plural vs singular) are minor deviations.
5 tools is well within the typical 3-15 range. The discovery+execute pattern allows broad platform coverage with a minimal surface, so each tool earns its place.
The server covers read-only GitLab operations: three specific getters plus dynamic discovery and execution of any read-only action, claiming 100% coverage. No write operations exist, but the read-only constraint is consistently enforced, so the surface is complete for its apparent scope.
LLM cost optimization gateway, repo token-waste auditor & model arbitrage MCP server.
Shared distillation cache for AI agents — every fetch ~73-89% fewer tokens via a shared cache.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Up to 90% fewer tokens: deterministic, declared tool calls, each with a receipt and an audit trail.