Gitlab Api

Gitlab Api

CLI or API | MCP | Agent

Version: 25.46.0

Documentation — Installation, deployment, usage across the API, CLI, and MCPinterfaces, the integrated A2A agent server, and guidance for provisioning thebacking GitLab instance are maintained in theofficial documentation.

Overview

Gitlab Api is a production-grade Agent and Model Context Protocol (MCP) server designed to interface directly with GitLab API + MCP Server + A2A Server.

Key Features

• Consolidated Action-Routed MCP Tools: Minimizes token overhead and eliminates tool bloat in LLM contexts by grouping methods into optimized, togglable tool modules.
• Enterprise-Grade Security: Comprehensive support for Eunomia policies, OIDC token delegation, and granular execution context tracking.
• Integrated Graph Agent: Built-in Pydantic AI agent supporting the Agent Control Protocol (ACP) and standard Web interfaces (AG-UI).
• Native Telemetry & Tracing: Out-of-the-box OpenTelemetry exports and native Langfuse tracing.

CLI or API

This agent wraps the GitLab API + MCP Server + A2A Server API. You can interact with it programmatically or via its integrated execution entrypoints.

Detailed instructions on how to use the underlying API wrappers, extended schema bindings, and developer SDK references are maintained in docs/index.md.

MCP

This server utilizes dynamic Action-Routed tools to optimize token overhead and maximize IDE compatibility.

Tool surface — MCP_TOOL_MODE

Set MCP_TOOL_MODE (in the shared ~/.config/agent-utilities/config.json or env):condensed (default — the action-routed tools below), verbose (one named 1:1 toolper API method, e.g. gitlab_get_branches(...), tagged verbose), or both. Filterthe verbose set with --tools tag:verbose / MCP_ENABLED_TAGS=verbose. See theagent-utilities MCP Tool Modes guide.

Available MCP Tools

Auto-generated from the live MCP server — do not edit by hand.

27 action-routed tools (default MCP_TOOL_MODE=condensed). Each is enabled unless its toggle is set false; set MCP_TOOL_MODE=verbose (or both) for the 1:1 per-operation surface. Auto-generated — do not edit.

Detailed tool schemas, parameter shapes, and validation constraints are preserved in docs/mcp.md.

Dynamic Tool Selection & Visibility

This MCP server supports dynamic toolset selection and visibility filtering at runtime. This allows you to restrict the set of exposed tools in order to prevent blowing up the LLM's context window.

You can configure tool filtering via multiple input channels:

• CLI Arguments: Pass --tools or --toolsets (or their disabled counterparts --disabled-tools and --disabled-toolsets) during startup.
• Environment Variables: Define standard environment variables:
  • MCP_ENABLED_TOOLS / MCP_DISABLED_TOOLS
  • MCP_ENABLED_TAGS / MCP_DISABLED_TAGS
• HTTP SSE Request Headers: Pass custom headers during transport initialization:
  • x-mcp-enabled-tools / x-mcp-disabled-tools
  • x-mcp-enabled-tags / x-mcp-disabled-tags
• HTTP SSE Request Query Parameters: Append query parameters directly to your transport connection URL:
  • ?tools=tool1,tool2
  • ?tags=tag1

When query strings or parameters are supplied, an LLM-free Knowledge Graph resolution layer (using DynamicToolOrchestrator) matches query intents against known tool tags, names, or descriptions, with safe fallback and automated 24-hour background cache refreshing.

MCP Configuration Examples

Install the slim [mcp] extra. All examples below installgitlab-api[mcp] — the MCP-server extra that pulls only the FastMCP /FastAPI tooling (agent-utilities[mcp]). It deliberately excludes the heavyagent runtime (the epistemic-graph engine, pydantic-ai, dspy, llama-index,tree-sitter), so uvx/container installs are dramatically smaller and faster.Use the full [agent] extra only when you need the integrated Pydantic AI agent(see Installation).

stdio Transport (Recommended for local IDEs e.g., Cursor, Claude Desktop)

Configure your IDE's mcp.json to launch the MCP server via uvx:

{
  "mcpServers": {
    "gitlab-api": {
      "command": "uvx",
      "args": [
        "--from",
        "gitlab-api[mcp]",
        "gitlab-mcp"
      ],
      "env": {
        "GITLAB_URL": "your_gitlab_url_here",
        "GITLAB_TOKEN": "your_gitlab_token_here"
      }
    }
  }
}

Streamable-HTTP Transport (Recommended for production deployments)

Configure your client's mcp.json to launch the Streamable-HTTP server via uvx with explicit host and port definition:

{
  "mcpServers": {
    "gitlab-api": {
      "command": "uvx",
      "args": [
        "--from",
        "gitlab-api[mcp]",
        "gitlab-mcp"
      ],
      "env": {
        "TRANSPORT": "streamable-http",
        "HOST": "0.0.0.0",
        "PORT": "8000",
        "GITLAB_URL": "your_gitlab_url_here",
        "GITLAB_TOKEN": "your_gitlab_token_here"
      }
    }
  }
}

Alternatively, connect to a pre-deployed remote or local Streamable-HTTP instance:

{
  "mcpServers": {
    "gitlab-api": {
      "url": "http://localhost:8000/gitlab-api/mcp"
    }
  }
}

Deploying the Streamable-HTTP server via Docker:

docker run -d \
  --name gitlab-api-mcp \
  -p 8000:8000 \
  -e TRANSPORT=streamable-http \
  -e PORT=8000 \
  -e GITLAB_URL="your_value" \
  -e GITLAB_TOKEN="your_value" \
  knucklessg1/gitlab-api:mcp

The :mcp tag is the slim MCP-server image (built fromdocker/Dockerfile --target mcp, installing gitlab-api[mcp]). The default:latest tag is the full agent image (--target agent, gitlab-api[agent])which also bundles the Pydantic AI agent and the epistemic-graph engine — use itwhen you run gitlab-agent (the agent), not just the MCP server. SeeContainer images.

Additional Deployment Options

gitlab-api can also run as a local container (Docker / Podman / uv) or beconsumed from a remote deployment. TheDeployment guide has full, copy-pastemcp_config.json for all four transports — stdio, streamable-http,local container / uv, and remote URL:

• Local container / uv — launch the server from mcp_config.json via uvx,docker run, or podman run, or point at a local streamable-http container by url.
• Remote URL — connect to a server deployed behind Caddy athttp://gitlab-mcp.arpa/mcp using the "url" key.

Environment Variables

Package environment variables

Inherited agent-utilities variables (apply to every connector)

33 package + 14 inherited variable(s). Auto-generated from .env.example + the shared agent-utilities set — do not edit.

Every variable the server reads.

Connection & Credentials

The connector is single-host by default and multi-tenant when gitlab_instances isconfigured (see Multi-Tenancy). When noinstances are configured, it falls back to the single-host GITLAB_* values below.

Multiple instances are declared once under gitlab_instances in the sharedagent-utilities XDG config (~/.config/agent-utilities/config.json) — each entry hasname, url, token, and verify_ssl. Target a tenant by name from the clientfactory; an unset instance resolves to the first configured one (else GITLAB_URL /GITLAB_TOKEN).

MCP server / transport

Tool toggles

Each action-routed tool can be disabled individually via its toggle env var (set to false).The full list is in the Available MCP Tools table above(e.g. PROJECTSTOOL, MERGE_REQUESTSTOOL, PIPELINESTOOL, GRAPHQLTOOL, CUSTOM_APITOOL).

Telemetry & governance

Agent CLI (full [agent] runtime only)

See .env.example for a copy-paste starting point.

Agent

This repository features a fully integrated Pydantic AI Graph Agent. It communicates over the Agent Control Protocol (ACP) and interacts seamlessly with the Agent Web UI (AG-UI) and Terminal interface.

Running the Agent CLI

To start the interactive command-line agent:

# Set credentials
export GITLAB_URL="your_value"
export GITLAB_TOKEN="your_value"

# Run the agent server
gitlab-agent --provider openai --model-id gpt-4o

Docker Compose Orchestration

The following docker/agent.compose.yml configures the Agent, Web UI, and Terminal Interface together:

version: '3.8'

services:
  gitlab-api-mcp:
    image: knucklessg1/gitlab-api:mcp
    container_name: gitlab-api-mcp
    hostname: gitlab-api-mcp
    restart: always
    env_file:
      - ../.env
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=8000
      - TRANSPORT=streamable-http
    ports:
      - "8000:8000"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  gitlab-api-agent:
    image: knucklessg1/gitlab-api:latest
    container_name: gitlab-api-agent
    hostname: gitlab-api-agent
    restart: always
    depends_on:
      - gitlab-api-mcp
    env_file:
      - ../.env
    command: [ "gitlab-agent" ]
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=9017
      - MCP_URL=http://gitlab-api-mcp:8000/mcp
      - PROVIDER=${PROVIDER:-openai}
      - MODEL_ID=${MODEL_ID:-gpt-4o}
      - ENABLE_WEB_UI=True
      - ENABLE_OTEL=True
    ports:
      - "9017:9017"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:9017/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Detailed graph node architecture explanations, custom skill configurations, and agentic trace guides are available in docs/agent.md.

Multi-Tenancy (multiple GitLab instances)

The client is natively multi-tenant. The set of instances is declared once in theshared agent-utilities XDG config (~/.config/agent-utilities/config.json) undergitlab_instances — the same list the Knowledge-Graph GitLab indexer reads, so oneconfig drives both code/metadata indexing and every API/MCP call:

{
  "gitlab_instances": [
    {"name": "internal", "url": "https://gitlab.arpa", "token": "glpat-xxxx", "verify_ssl": false},
    {"name": "public",   "url": "https://gitlab.com",  "token": "glpat-yyyy", "verify_ssl": true}
  ]
}

Target a tenant by name from the client factory; a bare URL still works, and anunset instance resolves to the first configured one (else GITLAB_URL/GITLAB_TOKEN):

from gitlab_api.auth import get_client
from gitlab_api.instances import list_configured_instances

internal = get_client(instance="internal")   # resolves url+token+verify from config
public   = get_client(instance="public")
default  = get_client()                        # first configured / GITLAB_URL fallback
names    = [i.name for i in list_configured_instances()]

The MCP server exposes a gitlab_instances tool (action=list|get) to discover theconfigured tenants (tokens are never returned). When no instances are configured, theconnector falls back to the single-host GITLAB_URL/GITLAB_TOKEN it has always used.

Security & Governance

Built directly upon the enterprise-ready agent-utilities core, standard security parameters are fully supported:

Access Control & Policy Enforcement

• Eunomia Policies: Fine-grained, policy-driven tool authorization. Supports none, local embedded (mcp_policies.json), or centralized remote modes.
• OIDC Token Delegation: Compliant with RFC 8693 token exchange for flowing authenticating user credentials from Web UI / ACP → Agent → MCP.
• Scoped Credentials: Execution context runs restricted to the specific caller identity.

Runtime Security Grid

Installation

Pick the extra that matches what you want to run:

# MCP server only (recommended for tool hosting — slim deps)
uv pip install "gitlab-api[mcp]"

# Full agent runtime (Pydantic AI + epistemic-graph engine)
uv pip install "gitlab-api[agent]"

# Everything (development)
uv pip install "gitlab-api[all]"      # or: python -m pip install "gitlab-api[all]"

Container images (:mcp vs :agent)

One multi-stage docker/Dockerfile builds two right-sized images, selected by --target:

docker build --target mcp   -t knucklessg1/gitlab-api:mcp    docker/   # slim MCP server
docker build --target agent -t knucklessg1/gitlab-api:latest docker/   # full agent

docker/mcp.compose.yml runs the slim :mcp server; docker/agent.compose.yml runs theagent (:latest) with a co-located :mcp sidecar.

Knowledge-graph database (epistemic-graph)

The full agent ([agent] / :latest) embeds the epistemic-graph engine (pulled intransitively via agent-utilities[agent]). For production — or to share one knowledge graphacross multiple agents — run epistemic-graph as its own database container and point theagent at it instead of embedding it. Deployment recipes (single-node + Raft HA), connectionconfig, and the full database architecture (with diagrams) are documented in theepistemic-graph deployment guide.The slim [mcp] server does not require the database.

Documentation

The complete documentation is published as theofficial documentation site and is therecommended reference for installation, deployment, and day-to-day operation.

Repository Owners

Contribute

Contributions are welcome! Please ensure code quality by executing local checks before submitting pull requests:

• Format code using ruff format .
• Lint code using ruff check .
• Validate type-safety with mypy .
• Execute test suites using pytest

Deploy with agent-os-genesis

This package can be provisioned for you — skill-guided — by the agent-os-genesisuniversal skill (its single-package deploy mode): it picks your install method, seedssecrets to OpenBao/Vault (or .env), trusts your enterprise CA, registers the MCPserver, and verifies it — the same machinery that stands up the whole Agent OS, narrowedto just this package. Ask your agent to "deploy gitlab-api with agent-os-genesis".

Secrets are read-existing + seeded via vault_sync — you are only prompted for what's missing.