GitLab MCP Server Setup in Cursor IDE (2026): mcp.json + Error Fixes

How do you set up the GitLab MCP server in Cursor? Add a GitLab entry under mcpServers in Cursor's mcp.json. GitLab's Cursor install page uses HTTP transport and the URL https://<gitlab.example.com>/api/v4/mcp. On GitLab.com that host is gitlab.com, so the URL is https://gitlab.com/api/v4/mcp. Save the file and complete the browser OAuth grant GitLab opens. Restart Cursor if the authorization page does not appear. Then start a new chat and ask something that requires a live GitLab tool, such as the version of the MCP server you are connected to.

This page owns GitLab MCP in Cursor. It is the Cursor-specific setup for GitLab's own server: the mcp.json block GitLab publishes for Cursor, OAuth Dynamic Client Registration, the Self-Managed URL, the optional mcp-remote stdio proxy, the tools GitLab documents, and the errors GitLab and Cursor actually log.

This is not a GitHub, Jira, Linear, Bitbucket, or Stripe guide. Those have their own articles.

Use the official GitLab MCP server

The maintained server is GitLab's first-party MCP endpoint on your GitLab instance. GitLab documents it at GitLab MCP server. The URL path is /api/v4/mcp.

GitLab publishes two transports:

Why older GitLab MCP tutorials fail in Cursor

Three published facts matter more than leftover 2025 screenshots.

The supported distribution changed. GitLab Cursor page uses a remote url of https://HOST/api/v4/mcp and OAuth. It does not use the old community package names or a token env var from archived tutorials.

Cursor schema is not VS Code schema. Cursor MCP reference uses a top-level mcpServers object. GitLab Visual Studio Code Copilot snippet walks through MCP: Add Server and can write a workspace vscode/mcp.json. Pasting a VS Code fragment into Cursor is a common reason the server never appears. GitLab Cursor snippet already uses mcpServers.

The GitLab MCP server is a beta product. GitLab introduced it as an experiment in GitLab 18.3 behind the mcp_server and oauth_dynamic_client_registration flags. It became beta in GitLab 18.6 and those flags were removed. GitLab 18.7 added support for the 2025-03-26 and 2025-06-18 MCP protocol specifications. GitLab 19.2 moved the feature from GitLab Premium to GitLab Free and made access a separate setting. The docs currently list the tier as Free, Premium, Ultimate, and the offering as GitLab.com, GitLab Self-Managed, and GitLab Dedicated. Tool availability still depends on the GitLab version you are talking to. A tool introduced in 19.3 is not on an 18.6 instance.

Prerequisites

From GitLab MCP server page, GitLab group and instance access pages, and Cursor MCP docs:

Step 1: Turn the GitLab MCP server on

GitLab will return 404 Not Found on /api/v4/mcp if these switches are off. Do this before you edit Cursor.

GitLab Duo availability and beta features

GitLab MCP prerequisites: set GitLab Duo availability to Always on or On by default, then turn on beta and experimental features.

On GitLab.com, GitLab Duo availability page: Search or go to the top-level group. Settings, GitLab Duo, Change configuration. Under GitLab Duo availability, select Always on or On by default. Under Feature preview, select Turn on experiment and beta GitLab Duo features. Save changes.

On GitLab Self-Managed and Dedicated, the same two ideas live on the instance. GitLab Duo page for Self-Managed (17.4 and later): Admin, Settings, GitLab Duo, Change configuration. Availability is Always on or On by default. The beta checkbox label GitLab prints is Use experiment and beta GitLab Duo features.

Allow access to the MCP server

This is a separate control from Duo availability. GitLab 19.2 made it generally available and removed the mcp_server_availability_setting flag.

GitLab.com (Owner role on the top-level group), from GitLab group access page: Search or go to the top-level group. Settings, General, expand Permissions and group features. In MCP client access, select Allow connection to GitLab. Save changes.

Self-Managed and Dedicated (administrator), from GitLab visibility and access controls page: Admin, Settings, General. Expand Visibility and access controls. In MCP client access, select Allow connection to GitLab. Save changes.

GitLab states that turning this setting off makes the MCP API reject all requests. The troubleshooting page names the denial reasons in mcp.log: instance_setting_disabled on Self-Managed, no_enabled_namespace on GitLab.com when no top-level group you belong to has the server turned on.

Step 2: Add GitLab Cursor HTTP block

Cursor reads MCP config from two files and merges them. Project-level wins if the same server name appears in both.

GitLab Cursor section walks the UI path Settings, Cursor Settings, Tools and MCP, then New MCP Server under Installed MCP Servers, which opens mcp.json. Cursor own help also documents Customize, MCPs and the same two file paths. Either path lands in the same schema. The top-level key is mcpServers. That is Cursor schema.

GitLab published Cursor block. Replace gitlab.example.com with gitlab.com on GitLab.com, or with your instance hostname on Self-Managed:

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://<gitlab.example.com>/api/v4/mcp"
    }
  }
}

GitLab.com form uses https://gitlab.com/api/v4/mcp as the url. The key GitLab is only a label in Cursor MCP panel. GitLab uses that spelling in the official snippet. The url is what connects.

Do not put a token in this block. GitLab Cursor page does not document a headers Authorization value for this server. First connect uses OAuth 2.0 Dynamic Client Registration: the client registers itself as an OAuth application, you approve access in the browser, and GitLab issues an access token.

Save the file. GitLab says wait for the browser OAuth page. If that does not happen, close and restart Cursor, then review and approve the request.

Step 3: Optional tool-name prefix

GitLab 18.11 added tool prefixing on HTTP transport. Send the header X-Gitlab-Mcp-Server-Tool-Name-Prefix. GitLab truncates the value to the first 32 characters. Use this if you run more than one GitLab instance, or if another MCP server already owns names such as search. GitLab example value is gitlab_.

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://<gitlab.example.com>/api/v4/mcp",
      "headers": {
        "X-Gitlab-Mcp-Server-Tool-Name-Prefix": "gitlab_"
      }
    }
  }
}

Step 4: Optional stdio path with mcp-remote

Use this when a client cannot speak HTTP to GitLab directly. GitLab documents it as the second official transport, not as the Cursor default. Cursor GitLab page uses HTTP. Prerequisites GitLab lists: Node.js 20 or later. If npx is installed locally instead of globally, GitLab says to put the full path to npx in command.

{
  "mcpServers": {
    "GitLab": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<gitlab.example.com>/api/v4/mcp"
      ]
    }
  }
}

The published package name on this path is mcp-remote. GitLab troubleshooting page uses npx -y mcp-remote@latest with the same /api/v4/mcp URL and --static-oauth-client-metadata with scope mcp. The OAuth scope GitLab prints there is mcp. GitLab also warns that pinning a specific mcp-remote version is for version-specific bugs only, and that you should not pin versions if possible.

Step 5: Optional shared OAuth application

Skip this unless Dynamic Client Registration is a problem. GitLab added UI creation of a reusable OAuth application in GitLab 19.3. Self-Managed and Dedicated can accumulate one OAuth application per client connect. GitLab rate-limits DCR to 10 registrations per hour per IP. A corporate egress IP can hit that cap. A shared application is the OAuth client identity, not a shared login. Every user still authorizes and gets their own access token.

GitLab create steps: create an OAuth application for the instance, a group, or a user. For scopes, select mcp and clear the Confidential checkbox. Save. The application ID is the clientId. Give that ID to the MCP client. GitLab says the config key is typically clientId or client_id in the GitLab MCP server OAuth configuration, usually in an mcp.json file.

The redirect URI on the GitLab application must exactly match the URI the client sends. GitLab says one shared application cannot serve clients that use different redirect URIs. Cursor MCP reference documents fixed MCP OAuth redirect URLs: desktop app http://localhost:8787/callback, and web and Cursor Agents https://www.cursor.com/agents/mcp/oauth/callback.

Cursor also documents a static auth object on remote url entries when you have a fixed Client ID instead of Dynamic Client Registration. The fields Cursor names are CLIENT_ID (required), CLIENT_SECRET (optional; GitLab told you to clear Confidential), and scopes (optional; if omitted, Cursor discovers scopes_supported from /.well-known/oauth-authorization-server). GitLab required OAuth scope for this application is mcp. Cursor supports env interpolation inside auth values. This page does not invent a Client ID.

GitLab security notes on a shared app: GitLab does not verify which MCP client software presents the clientId. Pre-registered applications created through the REST API do not enforce PKCE, though GitLab accepts code_challenge if the client sends it.

Step 6: Restart Cursor and verify

GitLab Cursor page: save mcp.json, complete the browser OAuth grant, restart Cursor if the page never opens, then start a new chat and ask a question that matches an available tool.

Cursor MCP help, for the client-side check: confirm the server is listed under Customize, MCPs (or Settings, Tools and MCP). In chat, confirm GitLab tools appear under Available Tools. Cursor asks for approval before MCP tools run, unless you changed the approval mode. Cursor 3.6 and above default to Auto-review under Settings, Agents, Approvals and Execution: allowlisted MCP tools run immediately and the rest go through a classifier. Allowlist keeps the older allowlist-only behavior. See Cursor IDE MCP Agent Mode.

A first prompt GitLab documents on the tools page: What version of the GitLab MCP server am I connected to? That calls get_mcp_server_version.

If the server is listed but chat never calls a tool, open logs. Cursor MCP FAQ: Output panel, Command-Shift-U on macOS or Control-Shift-U on Windows and Linux, then MCP Logs. GitLab Cursor troubleshooting names the Output channel MCP:SERVERNAME. With the official key GitLab, GitLab example is MCP: user-GitLab.

GitLab own warning, quoted in substance: you are responsible for guarding against prompt injection when you use these tools. Use them on GitLab objects you trust.

Global vs project config

Use ~/.cursor/mcp.json for a GitLab connection you want in every workspace. Use .cursor/mcp.json in a project root when that repo should talk to a different GitLab host (for example GitLab.com in one repo and a Self-Managed instance in another). Cursor help says a project file can be committed so teammates get the same tools. The official HTTP block contains no secret. That is safe to commit. If you later add a Client Secret or any token, interpolate from the environment or keep the secret out of git.

GitLab mcp.json configuration reference

This is every field the GitLab entry in Cursor's mcp.json actually uses, in one place, for people who landed here already knowing they need the configuration, not the walkthrough.

A minimal, complete GitLab.com entry is the four lines GitLab publishes:

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://gitlab.com/api/v4/mcp"
    }
  }
}

Configuring more than one GitLab instance in the same mcp.json

Cursor's mcpServers object accepts any number of keys, so a GitLab.com connection and a Self-Managed connection can live in the same file under different names:

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://gitlab.com/api/v4/mcp"
    },
    "GitLab-Internal": {
      "type": "http",
      "url": "https://gitlab.internal.example.com/api/v4/mcp"
    }
  }
}

Each key gets its own OAuth grant and its own entry under Available Tools, distinguished by the key name. This is also how you avoid the duplicate-key problem below when a project needs a different host than your global default.

mcp.json configuration mistakes that keep GitLab from appearing

Trailing comma after the last field. mcp.json is strict JSON, not JSON5. A trailing comma after "url": "..." or after the last server entry makes the whole file fail to parse, and Cursor drops every server in it, not just GitLab. Run the file through any JSON validator before restarting Cursor if a server that worked yesterday is suddenly gone.

Same key name in both files. If GitLab exists in both ~/.cursor/mcp.json and .cursor/mcp.json, the project-level entry wins for that workspace and the global one is not merged with it. If your project inherits an org-wide GitLab entry you did not expect, check .cursor/mcp.json in the repo root first.

url present but type omitted, next to a command-based server. Usually harmless, but if GitLab is not appearing while a stdio server in the same file works fine, add "type": "http" explicitly rather than relying on inference. It costs nothing and removes one variable when debugging.

Pasting the VS Code mcp.json shape instead of Cursor's. Covered above, worth repeating here because it is a configuration error, not a GitLab error: GitLab's VS Code docs write to a workspace .vscode/mcp.json with a different top-level shape. The Cursor file must have mcpServers at the top level, exactly as in the block above.

What the official tools actually do

GitLab publishes the inventory at GitLab MCP server tools. Names below are that page names. Several tools arrived after the 18.6 beta, so treat the live tools page as source of truth for your instance. This page does not invent extra tools.

Identity: get_mcp_server_version (18.3) returns the current MCP server version.

Issues and work items: create_issue (18.4) requires project id and title. get_issue (18.4) takes project id and issue_iid. save_work_item (19.4) creates or updates a work item; create_work_item and update_work_item are aliases. list_work_items (19.4). create_workitem_note and get_workitem_notes (18.7). link_work_items (19.0). get_saved_view_work_items (18.11).

Merge requests: create_merge_request (18.5; assignees, reviewers, description, labels, milestone in 18.8) requires project id, title, source_branch, and target_branch. get_merge_request (18.4; url and include facets in 19.3) returns one MR. include may be diffs, commits, notes, pipelines, or discussions, one facet per call. The diffs facet is statistics only; patch text is get_merge_request_diffs. list_merge_requests (19.3). get_merge_request_commits, get_merge_request_diffs, get_merge_request_pipelines (18.4). create_merge_request_note and get_merge_request_notes (19.2). GitLab rejects a note body whose lines start with /, to avoid quick actions such as /merge. save_merge_request_review (19.4) performs one review action per call: create_note, reply_discussion, create_diff_note, or resolve_discussion.

Repository: add_branch (19.3; alias create_branch) adds a branch from a ref. get_repository_file (19.3) returns one file at a ref from the repository, not from your working tree. get_commit (19.3).

CI/CD: get_pipeline (19.3), get_pipeline_jobs (18.4), get_job (19.3; get_job_log remains an alias), list_pipelines (19.3). save_pipeline (19.3) runs, retries, or cancels. manage_pipeline (18.10) updates metadata or deletes. GitLab tells you not to confuse manage_pipeline with save_pipeline.

Search and wiki: search (18.4; renamed from gitlab_search in 18.8). search_labels (18.9). list_wiki_pages (19.3).

Other documented tools: list_duo_sessions (19.3) lists Duo Agent Platform sessions, not Duo Chat. semantic_code_search requires a GitLab Duo Core, Pro, or Enterprise add-on on GitLab.com or Self-Managed; GitLab documents a long feature-flag history. attach_scan_profile (19.2).

Project identifiers on these tools are the numeric ID or the URL-encoded path (group/subgroup/project). GitLab examples use both 123 and gitlab-org/gitlab.

New tools since GitLab 19.3 (check your instance version before assuming these are live)

GitLab's tools page grew substantially in the 19.3 and 19.4 releases. If your Self-Managed instance is still on an older version, none of these will show up in Available Tools regardless of what your mcp.json looks like — that's a GitLab-version gap, not a Cursor config problem.

Introduced in 19.3: add_commit (adds a commit with one or more file actions to a branch in a single call — useful for multi-file edits Cursor would otherwise need several round-trips to make), list_duo_sessions (already covered above), save_merge_request (an alternate create/update entry point for merge requests, alongside the create_merge_request tool covered above — treat the live tools page as authoritative if the two ever diverge on behavior).

Introduced in 19.4: get_project (returns project metadata — numeric ID, full path, default branch, visibility, web URL — useful as a first call before other tools that need the numeric ID rather than the path), get_duo_session (checks the status of a Duo Agent Platform session), list_project_members (lists members with role and access level), get_user (resolves a username to a numeric user ID, which several other tools require instead of a username string), accept_merge_request (merges a merge request or schedules auto-merge — treat this as a write tool worth pausing on, same as create_merge_request), fork_repository, list_branches, list_releases, list_tags, get_work_item (a single work item's type, dates, assignees, and labels), list_projects, and list_groups (for navigating group hierarchy and discovering group IDs).

The practical effect of the 19.4 batch is that Cursor can now resolve names to IDs on its own — get_user and get_project remove a step that previously required you to paste a numeric ID into the prompt yourself.

GitLab 19.5: session input and toolset selection

GitLab 19.5 added send_duo_session_input, which answers a GitLab Duo Agent Platform session that's waiting for input — approving or rejecting a pending plan or tool call, or replying to a question the agent asked mid-session. Paired with start_duo_session, this is a different interaction shape than the request/response tools covered above: rather than one call returning one result, a Duo Agent Platform session can pause and wait for a human decision, and send_duo_session_input is how that decision gets sent back through the same MCP connection. If you're only using the request/response tools (issues, merge requests, pipelines), these two are not relevant — they matter specifically for teams driving GitLab's own agent sessions through Cursor rather than calling individual GitLab tools directly.

GitLab 19.5 also added get_artifact_file, for pulling a single file out of a CI/CD job's artifacts archive rather than downloading the whole archive to inspect one file.

As with the 19.3 and 19.4 batches, none of the 19.5 tools appear in Available Tools on an instance still running an older minor version — check Admin, before assuming a stale tool list is a Cursor-side problem.

Prompts that match documented tools

These are GitLab own examples or close paraphrases. Use a real project path, issue IID, and merge request IID the signed-in account can see.

Cursor will prompt you to approve write tools. Approve get_issue or get_merge_request freely. Pause on create_merge_request, create_issue, save_pipeline, manage_pipeline, and save_merge_request_review until you have read the arguments. GitLab note tool will not run /merge for you; do not try to smuggle quick actions through body.

Self-Managed and Dedicated

Same Cursor schema. Only the host changes. Point url at https://gitlab.example.com/api/v4/mcp and replace the hostname with the one users already open in a browser. GitLab snippets use https. This page does not invent a TLS-bypass environment variable.

Self-Managed also needs the instance administrator to allow MCP client access, plus Duo availability and beta features at instance scope. A 404 after OAuth is the setting, not a bad Cursor JSON key. If many developers share one egress IP, use the shared OAuth application path from Step 5. GitLab DCR cap is 10 registrations per hour per IP.

The experimental glab stdio server is a different binary

GitLab CLI documents glab mcp serve as an experiment. It starts a local stdio MCP server with command glab and args mcp serve. GitLab says it is not ready for production and might be removed. The Cursor install GitLab publishes is the HTTP /api/v4/mcp server, not glab. Do not mix the two configs and expect one OAuth grant to cover both.

Troubleshooting

404 Not Found on start, or on POST /api/v4/mcp after OAuth. GitLab: you have not met the prerequisites. Check mcp.log for denial_reason. instance_setting_disabled means the Self-Managed instance setting is off. no_enabled_namespace means no GitLab.com top-level group you belong to has the server on. A 404 inside a tool call, such as project not found, is not written to mcp.log; GitLab puts it in the JSON-RPC body with isError true.

Server never appears in Cursor. Confirm the file is ~/.cursor/mcp.json or .cursor/mcp.json. Confirm the top-level key is mcpServers. Invalid JSON drops every server in the file. Restart Cursor completely.

OAuth page never opens. GitLab Cursor page: close and restart Cursor. For the stdio path, GitLab says to delete ~/.mcp-auth/mcp-remote* while debugging, because MCP auth is cached locally and can produce false positives.

Error: Server protocol version is not supported: 2025-06-18. GitLab documents this on 18.6 and earlier when the MCP client library does not support the server protocol specification. GitLab fix is to ask the AI tool provider to update the client. GitLab 18.7 added explicit support for the 2025-06-18 spec.

Tool is missing. Check the GitLab version that introduced it. list_merge_requests is 19.3. create_issue is 18.4. semantic_code_search has its own add-on and flag history. The 19.4 batch (get_project, get_user, accept_merge_request, list_branches, list_releases, list_tags, list_projects, list_groups, and others) is new enough that a Self-Managed instance even a couple of minor versions behind will not have it — check your instance's GitLab version under Admin, before assuming Cursor or the MCP config is at fault.

Writes fail, reads work. The signed-in GitLab user cannot perform that action in the UI, or you denied the Cursor approval prompt. The official Cursor path does not have a GitLab-documented read-only URL suffix.

stdio mcp-remote issues. GitLab: Node.js 20+, full path to npx if it is not global, --debug on the npx command, optional mcp-remote-client. Cursor MCP Logs and GitLab MCP: user-GitLab Output channel are the client-side views.

429 Too Many Requests on repeated tool calls. GitLab rate-limits the MCP endpoint the same way it rate-limits the REST API — a loop that calls list_issues per-project across a large group can trip it. Cursor surfaces this as a generic tool error, not a labeled 429; check MCP Logs for the status code before assuming the tool itself is broken. Batch the request (ask for one JQL-style filter across the group instead of N per-project calls) rather than retrying immediately.

Corporate proxy or VPN blocks the connection. The GitLab Cursor HTTP transport needs outbound access to your GitLab host on 443. A split-tunnel VPN that routes gitlab.com traffic differently than general internet traffic is a common reason the server times out for one engineer on a team and not others. Confirm with curl -I https://gitlab.com/api/v4/mcp from the same machine and network Cursor runs on before debugging the JSON config further.

Looking for GitHub, Jira, Linear, or Bitbucket?

This URL is GitLab projects, issues, merge requests, and pipelines through GitLab official MCP server. GitHub repositories and pull requests are on GitHub MCP Server Cursor IDE Setup. Jira is on Jira MCP Server Cursor IDE Setup. Linear is on Linear MCP Server Cursor IDE Setup. Bitbucket Cloud is on Bitbucket MCP Server Cursor IDE Setup. Do not add GitHub, Jira, or Linear keys to the GitLab url block.

Frequently Asked Questions

Does the GitLab MCP server use a Personal Access Token in Cursor? Not on the path GitLab documents for Cursor. GitLab Cursor snippet is a remote url plus OAuth. A token-and-npx block belongs to the archived community server, not to this page.

What is the official URL? https://gitlab.com/api/v4/mcp on GitLab.com. https://YOUR-HOST/api/v4/mcp on Self-Managed or Dedicated. The REST API root /api/v4 is not the MCP endpoint.

Do I need Node.js? Not for GitLab Cursor HTTP transport. Yes, Node.js 20 or later, if you use mcp-remote.

Does this work on Self-Managed? GitLab lists GitLab Self-Managed and GitLab Dedicated. The Cursor JSON is the same. The administrator must allow MCP client access and turn on Duo availability plus beta features. Your instance must be new enough to host the server (experiment in 18.3, beta in 18.6, HTTP transport in 18.6).

Which OAuth scope does GitLab use? GitLab reusable-application instructions and the mcp-remote troubleshooting command use the scope mcp.

Can I restrict which projects the assistant sees? GitLab OAuth token acts as the user who approved it. The user can access only the data they are permitted to. GitLab does not document an MCP-config allowlist of project paths.

What happened to the old community GitLab MCP package? That community reference server was archived. GitLab official Cursor install does not use it. Use https://gitlab.com/api/v4/mcp or your instance equivalent.

Should I put the config in the project or my home directory? Use ~/.cursor/mcp.json for a GitLab connection you want everywhere. Use .cursor/mcp.json when one project needs a different host or tool-name prefix. The official HTTP block has no secret.

What is the minimum GitLab mcp.json configuration in Cursor? Three fields: the GitLab key name, "type": "http", and "url" pointing at /api/v4/mcp on your instance. No headers, no command, no args, no token. See the configuration reference above for every optional field and what each one does.

Can I configure two GitLab instances, like GitLab.com and a Self-Managed server, in one mcp.json? Yes. Give each entry a different key under mcpServers, for example GitLab and GitLab-Internal, each with its own url. They authorize and appear as separate tool sets in Cursor.

Why did GitLab disappear from Cursor after I edited mcp.json for something else? Almost always a JSON syntax error elsewhere in the same file, most often a trailing comma. Invalid JSON drops every server in the file, not just the one you were editing. Validate the file, then restart Cursor.

Can I run GitLab MCP and GitHub MCP at once? Yes. They are independent mcpServers entries. Configure GitHub from GitHub MCP Server Cursor IDE Setup. Tell Cursor which forge you mean in the prompt.

Still stuck? Debug MCP Server Issues covers reading client logs. Cursor isolates a crashed MCP server from the others.

What's the full GitLab MCP server Cursor IDE setup 2026 process, start to finish? Confirm your GitLab version supports HTTP transport (18.6+), have a group owner or instance admin turn on MCP client access plus Duo availability and beta features, add the GitLab entry with "type": "http" and the /api/v4/mcp URL to mcp.json, restart Cursor, and approve the OAuth prompt. No token, no npx, no command field for the recommended path.

Is there a separate GitLab MCP server setup for merge requests versus issues, or is it one connection? One connection. list_merge_requests, create_issue, pipeline tools, and semantic code search all come from the same /api/v4/mcp endpoint and the same OAuth grant — there's no separate merge-request-only or issues-only server to configure.

What tools did GitLab add most recently to the MCP server? GitLab 19.5 added send_duo_session_input (answers a Duo Agent Platform session waiting for input) and get_artifact_file (pulls one file from a CI/CD job's artifacts archive). GitLab 19.4 added a batch of ID-resolution and listing tools: get_project, get_user, list_project_members, accept_merge_request, fork_repository, list_branches, list_releases, list_tags, get_work_item, list_projects, and list_groups, alongside get_duo_session. None of these appear in Cursor's Available Tools list if your GitLab instance is on an older version — check your instance version before assuming a config problem.

What is send_duo_session_input for? It answers a GitLab Duo Agent Platform session that's paused waiting for input — approving or rejecting a pending plan or tool call, or replying to a question the session asked. It's a different interaction shape than GitLab's other MCP tools, which are one-shot request/response calls; this one responds to an in-progress, paused session started with start_duo_session. It's only relevant if you're driving Duo Agent Platform sessions through Cursor, not for the issue, merge request, and pipeline tools covered elsewhere on this page.

Related guides

Official docs cited