Connect GitLab to ChatGPT: Manage Repos, Issues, and Team Access

If you need to connect GitLab to ChatGPT to automate DevOps workflows, manage issue tracking, or orchestrate user access, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and GitLab's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting GitLab to Claude or explore our broader architectural overview on connecting GitLab to AI Agents.

Giving a Large Language Model (LLM) read and write access to a complex DevOps platform like GitLab is a massive engineering challenge. You have to handle complex relational data payloads, deal with highly specific URL-encoded identifiers, and map GitLab's unique permission inheritance model into MCP tool definitions. Every time an API endpoint changes, your custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for GitLab, connect it natively to ChatGPT, and execute complex workflows using natural language.

The Engineering Reality of the GitLab API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC, implementing it against GitLab's highly specific API quirks is exceptionally painful.

If you decide to build a custom MCP server for GitLab, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with GitLab:

The id vs iid Trap

GitLab heavily utilizes two different identifiers for its resources. The id is the global, unique database identifier for a record. The iid (internal ID) is the number that users actually see in the UI, scoped to a specific project or group. For example, Merge Request #42 in the UI has an iid of 42, but its global id might be 109583.

LLMs constantly hallucinate here. When a user asks "Get me merge request 42", the LLM will naturally pass 42 into the id field of a standard CRUD API. GitLab will either return a 404 or worse, return an entirely unrelated merge request. An effective MCP server must explicitly define query schemas that separate project_id and iid, explicitly instructing the LLM on how to construct the request.

URL-Encoded Paths vs Numeric IDs

GitLab allows querying projects and groups by either their numeric ID or their namespace path (e.g., my-group/my-project). However, if you use the path, the API strictly requires it to be URL-encoded (e.g., my-group%2Fmy-project). LLMs are notoriously bad at applying consistent URL encoding to path parameters before dispatching JSON payloads. If your MCP server does not intercept and encode these strings, or explicitly instruct the LLM on the formatting rules within the JSON Schema descriptions, API calls will continuously fail with 400 Bad Request errors.

Inherited vs Direct Memberships

GitLab's permission model inherits members down from parent groups. A user might have Maintainer access to a project because they are in a parent group, not because they were directly added to the project.

The GitLab API separates these concepts. Querying /projects/:id/members only returns direct members. To see everyone who actually has access, you must query /projects/:id/members/all. If an LLM is tasked with auditing access, giving it the wrong endpoint tool will result in a false sense of security, reporting that a project has two members when it actually has fifty inherited members. Your MCP tool curation must account for these distinct endpoints.

Rate Limiting and Backoff Responsibilities

When giving an autonomous agent access to an API like GitLab, rate limits are a critical architectural concern.

It is important to note: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream GitLab API returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - whether that is your custom MCP client application or ChatGPT - is entirely responsible for reading those headers and executing the appropriate retry and backoff logic. Do not expect the MCP server to absorb rate limits on your behalf.

Step 1: Generating the GitLab MCP Server

Truto's MCP servers turn any connected GitLab integration into a JSON-RPC 2.0 endpoint. Truto derives tools dynamically from the integration's documented API resources. A tool only appears in the MCP server if it has a corresponding documentation entry - ensuring only curated, LLM-ready endpoints are exposed.

Each MCP server is scoped to a single integrated account (your specific connection to GitLab). The server URL contains a cryptographic token that routes the request and handles authentication. You can create this server via the Truto UI or programmatically via the API.

Method A: Via the Truto UI

If you are manually setting up an integration for internal use, the UI is the fastest path.

1. Navigate to the Integrated Accounts page in the Truto dashboard.
2. Select your connected GitLab account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., name, allowed methods, tag filters).
6. Copy the generated MCP server URL.

Method B: Via the Truto API

If you are building a product that programmatically deploys AI agents for your customers, you must generate MCP servers via the API.

Make a POST request to /integrated-account/:id/mcp, passing in the specific methods and tags you want to expose to the LLM.

curl -X POST https://api.truto.one/integrated-account/<GITLAB_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "GitLab Agent Server",
    "config": {
      "methods": ["read", "write"],
      "tags": ["issues", "repositories", "members"]
    }
  }'

The API validates that the requested filters will actually match available tools. It then generates a secure token, hashes it via HMAC for storage, and returns the URL.

{
  "id": "mcp_abc123",
  "name": "GitLab Agent Server",
  "config": {
    "methods": ["read", "write"],
    "tags": ["issues", "repositories", "members"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This single url string contains the routing intelligence and the authentication token needed to handle the JSON-RPC lifecycle. Treat it like a secret.

Step 2: Connecting the Server to ChatGPT

Once you have the URL, you must register it with your ChatGPT environment. The MCP protocol handles the rest dynamically via the tools/list handshake.

Method A: Via the ChatGPT UI

If you are using ChatGPT directly in the browser (requires Pro, Plus, Business, Enterprise, or Education tiers with Developer Mode enabled):

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Ensure Developer mode is toggled on.
3. Under MCP servers / Custom connectors, click to add a new server.
4. Enter a Name (e.g., "GitLab (Truto)").
5. Paste the Truto MCP URL into the Server URL field.
6. Click Save.

ChatGPT will immediately connect, perform the protocol handshake, and map the GitLab endpoints into callable tools.

Method B: Via Manual Config File

If you are wrapping ChatGPT in a custom local agent environment (or using Claude Desktop/Cursor), you configure the MCP server using a JSON configuration file. Truto's MCP servers communicate over HTTP POST, which can be bridged locally using the official Server-Sent Events (SSE) wrapper provided by the MCP specification.

Add the following to your MCP configuration file:

{
  "mcpServers": {
    "gitlab-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}

Security and Access Control

When exposing GitLab to an AI agent, you must restrict the blast radius. Truto provides four distinct mechanisms to lock down your MCP server payloads:

• Method Filtering: Use config.methods to strictly enforce what operation types the LLM can see. Pass ["read"] to restrict the server to get and list operations, ensuring the agent cannot accidentally create issues or alter permissions.
• Tag Filtering: Use config.tags to limit the functional surface area. If you only want an agent managing users, pass ["members", "users"]. Tools outside these categories are dynamically pruned during the tools/list initialization.
• API Token Authentication: By passing require_api_token_auth: true during creation, the server URL alone is no longer enough. The connecting client must also pass a valid Truto API token in the Authorization header, providing defense-in-depth.
• Automatic Expiration: Set an expires_at timestamp for temporary access. Truto relies on a Durable Object alarm to aggressively clean up the server and revoke KV access at the exact moment of expiration, ensuring contractor or temporary agent access is securely terminated.

Hero Tools for GitLab Management

Truto maps GitLab's vast API surface into highly specific, schema-enforced tools. The MCP router handles the flat input namespace from the LLM, mapping query parameters and body payloads to the exact structure GitLab expects.

Here are the highest-leverage tools available for your agent.

1. list_all_git_lab_repositories

Allows the agent to view the file and directory tree of a specific project, effectively functioning like git ls-tree. This is essential for agents attempting to navigate a codebase before making edits or answering architectural questions.

"List all the files in the root directory of the backend API project. Include the last commit info for each file so I can see what was recently updated."

2. create_a_git_lab_project_issue

Creates a new issue inside a specific project. The tool enforces the project_id and requires a title, allowing the LLM to format the description using markdown to include stack traces or context.

"Create a new issue in the frontend repository titled 'Fix memory leak in checkout component'. Add the recent Sentry error log to the description and set the due date for this Friday."

3. get_single_git_lab_merge_request_by_id

Retrieves the full details of a specific merge request. Because of Truto's explicit schema definitions, the LLM is instructed to use the iid (the internal ID visible in the UI) rather than confusing it with the global database ID.

"Pull the details for merge request #105 in the core-services project. Tell me if it has any merge conflicts and what the current pipeline status is."

4. list_all_git_lab_project_members

Retrieves the direct members of a specific project, excluding inherited members from parent groups. This is critical for auditing localized access and ensuring least-privilege principles at the project level.

"Show me all the direct members of the mobile-app repository and their current access levels."

5. update_a_git_lab_project_member_by_id

Modifies the access level of a specific direct member. This tool requires the project_id, the user's id, and the new integer-based access_level (e.g., 30 for Developer, 40 for Maintainer).

"Update Sarah's access level in the mobile-app repository to Maintainer so she can approve merge requests."

6. create_a_git_lab_issue_note

Allows the agent to comment on an existing issue. This is heavily utilized by automated triage agents that investigate alerts and leave detailed findings on the relevant issue ticket.

"Add a comment to issue #88 in the infrastructure repo summarizing our recent Datadog findings regarding the database latency spikes."

To view the complete inventory of available tools, query parameters, and required JSON schemas, visit the GitLab integration page.

Workflows in Action

When these tools are orchestrated by an LLM, complex engineering tasks collapse into single prompts. Here is how a DevOps or IT persona might deploy ChatGPT using the Truto MCP server.

Workflow 1: Automated Incident Triage

When an alert fires, a DevOps engineer uses ChatGPT to investigate the codebase, create a tracking issue, and begin collaboration.

"Look at the repository tree for the 'auth-service' project to find the latest changes. Create an issue titled 'Investigate JWT Validation Latency', assign it to the on-call engineer, and add a comment with a summary of the files that were modified in the last 24 hours."

1. list_all_git_lab_repositories: ChatGPT queries the file tree with the with_last_commit flag to identify recently modified files related to JWT validation.
2. create_a_git_lab_project_issue: The agent creates the tracking issue, passing the project_id and the requested title.
3. create_a_git_lab_issue_note: ChatGPT compiles its findings from the repository query and posts them as a formatted comment on the newly created issue using the returned iid.

sequenceDiagram
    participant User as User Prompt
    participant ChatGPT as ChatGPT
    participant Truto as Truto MCP Server
    participant API as "GitLab API"

    User->>ChatGPT: "Look at the repo tree..."
    ChatGPT->>Truto: tools/call (list_all_git_lab_repositories)
    Truto->>API: GET /projects/:id/repository/tree
    API-->>Truto: Tree Data
    Truto-->>ChatGPT: Tool Result
    
    ChatGPT->>Truto: tools/call (create_a_git_lab_project_issue)
    Truto->>API: POST /projects/:id/issues
    API-->>Truto: Issue Metadata (iid: 402)
    Truto-->>ChatGPT: Tool Result
    
    ChatGPT->>Truto: tools/call (create_a_git_lab_issue_note)
    Truto->>API: POST /projects/:id/issues/402/notes
    API-->>Truto: Note Created
    Truto-->>ChatGPT: Tool Result

Workflow 2: Secure Access Auditing

An IT administrator needs to execute an access review and update permissions based on organizational changes.

"List all direct members of the 'payment-gateway' project. Find the user ID for Marcus and update his access level to Developer."

1. list_all_git_lab_project_members: ChatGPT fetches the array of current direct members for the specified project_id.
2. Internal Processing: The LLM parses the JSON array, locates the record where username or name matches Marcus, and extracts his specific integer id.
3. update_a_git_lab_project_member_by_id: ChatGPT issues the update command, passing the project_id, Marcus's id, and the required access_level integer representing the Developer role.

Escaping the Integration Maintenance Trap

Building an AI agent that interfaces with GitLab requires more than just formatting JSON. You must navigate rate limits, properly encode path parameters, map complex permission structures, and constantly update schemas as the upstream API evolves. Every hour spent maintaining boilerplate integration code is an hour stolen from building actual AI logic.

By leveraging Truto's dynamically generated MCP servers, your engineering team escapes the maintenance trap. You define the tools via UI or API, pass the URL to ChatGPT, and instantly enable secure, heavily-curated, rate-limit-aware access to your GitLab resources.

Stop managing OAuth tokens and hunting down API schema changes. Focus on the prompts, and let Truto handle the protocol.