Product and engineering

The GitLab connector.

Projects, issues, merge requests and pipelines. Connect once with your own key. Every agent your team runs reads the same 6 tools under one permission model.

How access is governed

6

Read tools

Open by default. They run when called, and every call is logged with the endpoint, tool and capability.

0

Write tools

GitLab exposes no write tools. Nothing it does mutates external state.

0

Destructive tools

GitLab defines no destructive tools. Nothing here deletes data.

Defaults come from the capability on each tool definition, and an admin can tighten or open any tool individually. The endpoint's capability ceiling can only tighten that policy. An endpoint scoped to read never surfaces a write tool.

Every GitLab tool

6 tools, named as the agent sees them.

  • list_projectsread

    List GitLab projects the token can access, most recently active first. Use this first to find the project id that every other tool needs.

  • list_issuesread

    List issues in a project. Use the numeric project id (or full path) from list_projects. The returned `iid` is what get_issue takes.

  • get_issueread

    Get one issue with its full description. Takes the project id from list_projects and the issue `iid` from list_issues (the per-project number shown in the UI, not the global `id`).

  • list_merge_requestsread

    List merge requests in a project — use this to review what is awaiting merge. The returned `iid` is what get_merge_request takes.

  • get_merge_requestread

    Get one merge request with its full description and merge state. Takes the project id from list_projects and the MR `iid` from list_merge_requests.

  • list_pipelinesread

    List recent CI pipelines for a project. Use this to check whether a branch is green before asking about a merge request.

Use it from any agent

The same GitLab tools reach Claude Code, Cursor, Claude Desktop or your own agent through one MCP endpoint. The endpoint is scoped to a group, the token is issued per group and revocable from the dashboard, and an allowed-tool list and capability ceiling limit what it exposes. Reads run. Gated writes refuse unless an admin opens them. Destructive tools remain unavailable over MCP.

.mcp.json · works for Cursor and Claude Desktop too
{
  "mcpServers": {
    "growth": {
      "type": "http",
      "url": "https://app.notara.ai/mcp/g/acme/growth",
      "headers": {
        "Authorization": "Bearer ntr_mcp_xxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

The URL and token are placeholders. Real endpoints are issued per group from the dashboard.

Setup

  1. 01

    Create a GitLab Personal Access Token in your GitLab account (where to find it). The key is yours: Notara stores it encrypted and never sees a bill.

  2. 02

    Paste it into the Notara dashboard. Credentials can be scoped to the workspace or to one person.

  3. 03

    The tools appear with their capability defaults already set. Tighten or open any of them per tool, then invite the agent to a channel or issue an MCP token.

More in product and engineering

LinearCursorSentryAsanaClickUpNotion

Connect GitLab once. Use it everywhere.

Use Notara directly, or bring us the workflow that needs to be redesigned and built.

Book a callSign in