Connect Your AI Agent with GitLab for Slack

Updates an existing project issue. See the documentation

Updates an epic. See the documentation

Find merge requests whose title or description matches a search term. Use this when the user refers to a merge request by what it is about ("the MR about the Redis cache refactor", "the payments migration MR") rather than by number - it is the fastest way to turn a description into the iid that every other merge request tool needs. ALWAYS set Project (or Group) when you know which one the user means: a project-scoped search returns in well under a second, whereas an unscoped search scans every project the account can access and, on accounts that belong to many projects, can take tens of seconds and time out (HTTP 408). Leave both blank only when the project is genuinely unknown. Use List Merge Requests instead when there is no text to match and you only want to filter by state, author, reviewer or branch. Matching is case-insensitive substring, not fuzzy - prefer one or two distinctive words over a whole sentence. See the documentation

Search for issues in a repository with a query. See the documentation

Mark a merge request thread as resolved, or reopen a resolved one by setting Resolved to false. Use this after acting on a piece of review feedback — resolving threads is what clears a merge request's blocking_discussions_resolved flag so it can merge. Get the Discussion ID from List Merge Request Discussions (set its Only Unresolved to true to see just the threads still open). Only threads that are resolvable can be resolved: plain comments on the merge request as a whole are not, and GitLab rejects the attempt. See the documentation

Get a list of repository branches from a project. See the documentation

List or search GitLab projects, optionally filtering by search term, membership, or ownership. Use this to discover projects (and their IDs) before acting on them with other GitLab actions. Supports ordering by name, path, creation/update time, star count, last activity, or search similarity, plus pagination. The similarity order requires a Search term. See the documentation

List all members of a project. See the documentation

List the labels defined in a project. Call this before applying labels with Create Merge Request: GitLab creates a label it does not recognize rather than rejecting it, so an invented or mis-cased name silently adds a new project label instead of applying the intended one. Each result's name is the value to pass back; the description is worth reading because label names are often abbreviations. Narrow a long list with Search. See the documentation

Retrieves available options for the Project ID field.

List merge requests, filtered by project, group, state, author, assignee, reviewer, labels or target branch. Use this for any "what merge requests are …" question — open MRs in a project, MRs waiting on my review (set Scope to reviews_for_me), MRs assigned to me, MRs targeting a release branch. Use Search Merge Requests instead when you have text to match against a title or description. Set Project to scope to one project, Group to scope to a whole group, or leave both blank to search across everything the authenticated user can see — note that with both blank GitLab defaults Scope to created_by_me, so pass all to widen it. Results are summarized by default; set Detail to full for the complete merge request objects. The returned iid is what every other merge request tool needs. See the documentation

List the comment threads on a merge request — both general comments and inline threads anchored to lines of the diff. Use this to read existing review feedback before adding your own, to find what a reviewer objected to, or to get the id of a thread so you can reply to it with Create Merge Request Comment or close it with Resolve Merge Request Thread. Each thread's notes carry resolvable, resolved and, for inline threads, the position (file path and line) they are attached to. GitLab records label changes, assignments and other bookkeeping as system notes; those are filtered out by default because they are rarely what a reader wants — set Include System Notes to true to see them. Set Only Unresolved to true to get just the threads still needing attention. See the documentation

List all groups. See the documentation

Retrieves available options for the Group Path field.

Retrieves available options for the Group ID field.

List commits in a repository branch. See the documentation

Get a single project repository branch. See the documentation

Get a single merge request together with a readiness rollup that answers "can this be merged?" in one call — state, draft flag, detailed_merge_status, conflict flag, whether blocking threads are resolved, head pipeline status, and the approval count with who has approved. Use this to open or inspect a merge request, and before approving or merging one. It does not return the code changes: call Get Merge Request Diffs for those, and List Merge Request Discussions for existing review comments. If you only know the merge request by title, resolve its iid with Search Merge Requests first. The response also carries diff_refs, the commit SHAs needed to anchor inline comments — no other tool needs to fetch them. See the documentation

List the file-level changes in a merge request — each changed file's path, whether it was added, deleted or renamed, and its unified diff. This is the tool to call before reviewing, approving or commenting on a merge request: the new_path values and the line numbers inside each diff hunk are what Create Merge Request Comment and Create Merge Request Review need to anchor an inline comment. Large merge requests can be trimmed with Paths (only files under the given prefixes) and Max Files. Watch for too_large: true or collapsed: true on a file — GitLab omits or shortens those diffs, so do not conclude a file is unchanged. Use Get Merge Request for metadata and merge readiness, and Get Merge Request Commits for the commit history. See the documentation

List the commits contained in a merge request, newest first. Use this to understand how a change was built up — whether it is one clean commit or a long history to squash, who wrote each part, and what the commit messages claim. For the actual code changes call Get Merge Request Diffs instead; for merge readiness call Get Merge Request. See the documentation

Gets a single issue from repository. See the documentation

Open a new merge request from one branch into another. Use this for "open an MR", "raise a merge request", "submit my branch for review". Both branches must already exist in the project — use List Repo Branches to check, or Create Branch to make one. Reviewers and assignees are given as usernames and resolved to IDs automatically; a username that is not a member of the project is rejected rather than silently dropped. Set Draft to true for work that is not ready for review — GitLab expresses this by prefixing the title with Draft:, which this action does for you and which blocks merging until removed. After creating, use Get Merge Request to check its pipeline and merge readiness. See the documentation

Submit a whole review on a merge request in one step: any number of inline comments anchored to lines of the diff, an overall summary comment, and optionally an approval. This is the tool for "review this MR" — call Get Merge Request and Get Merge Request Diffs first to read the changes, then send the findings back here. GitLab has no single submit-review API, so this action posts each inline comment as its own thread and then approves if asked; if an individual comment is rejected (usually a line that is not part of the diff) the rest are still posted and the failures are returned in failed, so check that array rather than assuming everything landed. Line numbers follow GitLab's diff rules: new_line for a line the merge request adds, old_line for a line it removes, both for an unchanged context line. There is no REST equivalent of GitLab's Request changes state — to block a merge request, leave the findings as comments and do not approve. See the documentation

Post a comment on a merge request. It works in three modes, chosen by which props you set: leave File Path and Discussion ID blank for a plain comment on the merge request as a whole; set File Path plus a line number to open an inline thread anchored to that line of the diff; or set Discussion ID to reply inside an existing thread. Use Get Merge Request Diffs first to get valid file paths and line numbers, and List Merge Request Discussions to get a Discussion ID to reply to. Line numbers follow GitLab's diff rules: for a line the merge request adds or leaves unchanged, pass New Line; for a line it removes, pass Old Line; for an unchanged context line, pass both. Getting that wrong is the usual cause of a rejected inline comment. To post several review comments at once, and optionally approve in the same step, use Create Merge Request Review instead. See the documentation

Creates a new issue. See the documentation

Creates a new epic. See the documentation

Create a new branch in the repository. See the documentation

Approve a merge request as the authenticated user, or withdraw an earlier approval by setting Action to unapprove. Call Get Merge Request first to check the merge request is actually ready — its readiness rollup reports the pipeline status, conflicts and how many approvals are still required — and Get Merge Request Diffs to read the changes being approved. Two things commonly go wrong: GitLab refuses to let you approve your own merge request, and a project may require approval from a specific approval rule that the authenticated user does not satisfy; both surface as a 401. To approve as part of leaving review feedback in one step, use Create Merge Request Review with its Action set to approve instead. Optionally pass SHA to make the approval conditional on the merge request's head commit, so it fails rather than silently approving work that was pushed after you read the diff. See the documentation