Manage GitLab projects, issues, merge requests and CI/CD pipelines from Prisme.ai workflows and AI agents
The GitLab app provides read/write access to the GitLab DevOps platform via its REST v4 API. It can be used either as a Builder app (automations call GitLab instructions directly) or as a remote MCP server consumed by an Knowledges agent — covering projects, issues, merge requests, pipelines, branches, commits, releases, CI/CD variables, deploy keys, webhooks, wikis, groups and users. Supports two authentication modes:
Central OAuth2 (recommended) — one OAuth Application is registered once by the Prisme.ai workspace admin; every end user signs in with their own GitLab account. Nothing to install per tenant. Requires the platform admin to grant the GitLab capability in Prisme.ai Governance (see below).
Tenant PAT — install the GitLab app in your workspace and paste a Personal Access Token. Shared across the workspace’s users; no per-user sign-in.
Project Management
Projects, issues, merge requests, labels, milestones and wikis
CI/CD & DevOps
Pipelines, jobs, environments, CI variables, deploy keys and webhooks
Central OAuth or PAT
One shared OAuth Application with per-user sign-in, or a tenant-level static PAT — both modes coexist on the same MCP endpoint
For the central OAuth mode — the platform admin has registered ONE OAuth Application at User Settings > Applications (https://gitlab.com/-/user_settings/applications) with api scope and the callback URL <api-url>/workspaces/slug:gitlab/webhooks/oauthCallback, and has stored its Client ID + Client Secret in the Secrets of the central gitlab workspace. The end user only needs to click Connect once.
For the tenant PAT mode — a Personal Access Token with api scope (Preferences > Access Tokens), pasted into the installed app instance.
Base URL (default: https://gitlab.com/api/v4 — override for self-hosted instances)
The two modes are mutually exclusive per MCP call: callers identify themselves either by being authenticated to Prisme.ai (central) or by sending the mcp-api-key header (tenant). The same workspace can serve both at the same time.
The central OAuth flow is set up once per environment by the Prisme.ai workspace admin. End users never touch any of this.
1
Register the OAuth Application at GitLab
Open https://gitlab.com/-/user_settings/applications and click Add new application. Use these values:
Name — Prisme.ai GitLab connector (or whatever fits your branding)
Redirect URI — <api-url>/workspaces/slug:gitlab/webhooks/oauthCallback (e.g. https://api.studio.prisme.ai/v2/workspaces/slug:gitlab/webhooks/oauthCallback on production)
Scopes — api
Save and copy the Application ID + Secret (the Secret is shown only once).
2
Store the credentials in the gitlab workspace secrets
Open the central gitlab workspace in the Prisme.ai Builder (Studio), go to Workspace settings > Secrets and set:
gitlabOauthClientId — the Application ID from GitLab
gitlabOauthClientSecret — the Secret from GitLab
These secrets are scoped to the gitlab workspace itself — they are NOT exposed to the end users or to any tenant who installs the app.
3
Declare the OAuth authentication in Governance
Open Prisme.ai Governance > Capabilities > GitLab (or whichever capability your agents will use to consume the connector) and attach an authentication configuration that points at the three central webhooks of the gitlab workspace:
Replace <api-url> with your environment’s API URL (https://api.studio.prisme.ai/v2 on production). Governance uses these URLs to (1) probe whether the calling user is already connected (status_url), (2) trigger the OAuth handshake when they are not (connect_url), and (3) revoke the session on demand (disconnect_url).
4
Grant the capability to the right roles
Still in Governance, grant the GitLab capability to the roles or users who should be allowed to sign in with their own GitLab account through the central MCP. Without this grant, callers without an mcp-api-key header are rejected with 401 Authentication required.
5
Test the flow
From an Agent Creator agent with the GitLab capability enabled, call any tool (e.g. getCurrentUser). The agent receives a connect_url on the first call; opening it in a new window redirects the user to GitLab, then back to a callback page that closes itself after 5 seconds. Subsequent calls reuse the stored access token transparently.
Base URL of the GitLab API (default https://gitlab.com/api/v4). Override for self-hosted instances.
Personal Access Token
GitLab PAT with api scope, stored as a workspace secret. Required when calling the MCP endpoint with the mcp-api-key header (tenant mode). Leave empty to use the central OAuth shared by the platform admin.
MCP Endpoint
Auto-populated on install — URL of the MCP endpoint for this instance.
MCP API Key
Auto-populated on install — signed key used in the mcp-api-key header for tenant PAT mode. Do not modify.
OAuth credentials (Client ID / Client Secret / authorization URL / token URL / scopes) are NOT part of the app instance config anymore — they live in the Secrets of the central gitlab workspace and are shared by all callers in central mode. See the Setup section above.
Plug into an Agent Creator capability (central OAuth)
The preferred path for human-facing agents. End users sign in with their own GitLab account; tokens are stored against their Prisme.ai user identity, never shared with other users of the same workspace.
1
Prerequisites
The platform admin has completed the Setup section above: OAuth Application registered at GitLab, gitlabOauthClientId + gitlabOauthClientSecret stored in the gitlab workspace secrets, and the GitLab capability granted in Governance to the right roles.
2
Open Agent Creator
Switch to Agent Creator and open the agent you want to extend.
3
Add the GitLab capability
Add the GitLab capability to the agent. No URL, no mcp-api-key to paste — the central endpoint is pre-wired and the caller is identified by the Prisme.ai session of whoever is talking to the agent.
4
Brief the agent in its system prompt
Wiring the capability is not enough — the agent also needs to know the MCP exists and when to reach for it. Copy-pasteable starter:
You have access to the GitLab MCP server. Use it whenever the user asks about GitLab content — projects, issues, merge requests, pipelines, jobs, branches, commits, tags, releases, milestones or members. Examples: "List my open merge requests", "What's failing in pipeline #1234?", "Create an issue in project X with label bug", "Show the latest release of my main project". If the user is not yet connected, call the `connect` tool to obtain a sign-in link; if they are already connected, call the relevant data tool directly. Prefer calling MCP tools directly over guessing, and confirm with the user before any destructive action (close an issue, merge or revert an MR, delete a branch, cancel a pipeline).
Refine the trigger keywords (project names, group names, label conventions) so the agent reliably picks up the right intent in your context.
5
First call → sign-in
On the first GitLab tool call, the agent receives a connect_url. Open it in a new window: GitLab asks the user to authorize the application, then redirects back to a callback page that closes itself after 5 seconds. The agent retries the same tool call automatically.
Use this when one shared token is preferable to per-user OAuth — typical for service-account workflows, automations triggered by a non-interactive bot user, or environments where the central OAuth admin setup is not available.
1
Install the GitLab app in your workspace
Open the workspace Imports panel, search for GitLab and install it.
2
Paste a Personal Access Token
Open the freshly installed app instance settings, set the GitLab API Base URL (if not gitlab.com) and the Personal Access Token (with api scope). Save.
3
Copy the MCP endpoint and API key
Still on the app instance configuration page, copy the values of MCP Endpoint and MCP API Key — both are generated automatically on install. The endpoint is the same as the central one above; the mcp-api-key identifies your tenant.
4
Wire into Agent Creator
Add a new capability to the agent:
If a dedicated GitLab tenant capability exists — select it and paste the MCP API Key into the mcp-api-key field.
Otherwise — select the generic custom_mcp capability, paste the MCP Endpoint into the Server URL field, then add an mcp-api-key entry to the Headers field:
{ "mcp-api-key": "your-mcp-api-key"}
5
Save
The agent now calls GitLab through the tenant PAT — every user of this agent shares the same GitLab identity (the owner of the PAT).
The signed mcp-api-key encodes the workspace ID and a getConfig webhook URL. The MCP server validates the signature and resolves the tenant PAT ({{config.token}} → {{secret.gitlabToken}}) server-side. The connect / disconnect tools are filtered out of tools/list in tenant mode — they only make sense for central OAuth.
List accessible projects. By default returns ALL accessible projects including public ones. Pass membership: true or owned: true to limit to the user’s own projects.
“Authentication required: please sign in to Prisme.ai before calling the GitLab MCP without an mcp-api-key header” — A caller hit the central endpoint without a valid Prisme.ai session AND without an mcp-api-key. Either sign in to Prisme.ai (central mode) or pass the tenant mcp-api-key (tenant mode).“Central OAuth config missing” — The gitlabOauthClientId / gitlabOauthClientSecret secrets of the central gitlab workspace are empty. Ask the platform admin to complete the Setup section above.“GitLab capability not granted” — The current user is signed in to Prisme.ai but has not been granted the GitLab capability in Governance. Ask the platform admin.“Invalid mcp-api-key” (tenant mode) — The mcp-api-key header does not match the central app secret. Reinstall the app instance to regenerate a signed key.“This GitLab tenant has no Personal Access Token configured” — Tenant mode was used (mcp-api-key header present) but the app instance’s token field is empty. Either fill the token or drop the header to fall back to central OAuth.“Can’t approve own MR” — A GitLab project access token’s bot user counts as the MR author and cannot approve its own merge requests. Use a different token (PAT for a human user) for the approval step.“pipeline creation 404” — The target ref has no .gitlab-ci.yml at its root. Either commit a CI config first or pick a ref that has one.Central OAuth — disconnecting a user — In central mode, the agent calls the disconnect tool (or the user opens <api-url>/workspaces/slug:gitlab/webhooks/disconnectOAuth) to revoke the access token at GitLab (RFC 7009) and delete the stored secrets. The next data tool call returns a fresh connect_url.