Knuckles-Team/gitlab-api

GitLab API - A2A | AG-UI | MCP

Version: 25.15.23

Overview

This project started out as a python wrapper for GitLab, but since the dawn of standards like Model Context Protocol (MCP) and Agent2Agent (A2A) Agent, this repository has become a sandbox for some brand new and pretty cool features with respects to each of those. The original APIs should remain stable, but please note, the latest features like A2A may still be unstable as it is under active development.

This project now includes an MCP server, which wraps all the original APIs you know and love in the base project. This allows any MCP capable LLM to leverage these tools and interact with GitLab. The MCP Server is enhanced with various authentication mechanisms, middleware for observability and control, and optional Eunomia authorization for policy-based access control.

GitLab A2A implements a multi-agent system designed to manage and interact with GitLab tasks through a delegated, specialist-based architecture. Built using Python, it leverages libraries like pydantic-ai for agent creation, FastMCPToolset for integrating Model Context Protocol (MCP) tools, and Graphiti for building a temporal knowledge graph from official GitLab documentation. The system runs as a FastAPI server via Uvicorn, exposing an Agent-to-Agent (A2A) interface for handling requests. pydantic-ai is able to expose your agent as an A2A agent out of the box with .to_a2a(). This allows this agent to be integrated in any agentic framework like Microsoft Agent Framework (MAF) or crew.ai. The core idea is an orchestrator agent that analyzes user queries and delegates subtasks to specialized child agents, each focused on a specific domain (e.g., merge requests, pipelines). Child agents have access to filtered MCP tools and a shared knowledge graph for reasoning over documentation, ensuring accurate and context-aware executions without direct access to the underlying APIs from the orchestrator.

This architecture promotes modularity, scalability, and maintainability, making it suitable for enterprise integrations with platforms like GitLab.

Contributions are welcome!

API

API Calls

• Branches
• Commits
• Deploy Tokens
• Groups
• Jobs
• Members
• Merge Request
• Merge Request Rules
• Merge Request Rule Settings
• Namespaces
• Packages
• Pipeline
• Pipeline Schedules
• Projects
• Protected Branches
• Releases
• Runners
• Users
• Wiki
• Environments
• Protected Environments
• Tags
• Protected Tags
• Custom Endpoint

If your API call isn't supported, you can always run the standard custom API endpoint function to get/post/put/delete and endpoint

Experimental - GraphQL:

• Branches
• Groups
• Jobs
• Merge Request
• Pipeline
• Branches
• Users
• Wiki
• Projects

MCP

All the available API Calls above are wrapped in MCP Tools. You can find those below with their tool descriptions and associated tag.

MCP Tools

A2A Agent

Architecture Summary

The system follows a hierarchical multi-agent design:

• Orchestrator Agent: Acts as the entry point, parsing user requests and delegating to child agents based on domain tags.
• Child Agents: Domain-specific specialists (one per tag, e.g., "pipelines", "merge_requests") that execute tasks using filtered MCP tools and query the knowledge graph for guidance from official docs.
• Knowledge Graph (Graphiti): A centralized, temporal graph database ingesting GitLab documentation, accessible by child agents for retrieval-augmented reasoning.
• MCP Tools: Distributed via tags to ensure each child agent only accesses relevant tools, preventing overload and enhancing security.
• Server Layer: Exposes the orchestrator as an A2A API using pydantic-ai's to_a2a method and Uvicorn.

Key integrations:

• Pydantic-AI: Used for defining agents, models (e.g., OpenAI, Anthropic), and run contexts.
• A2A (Agent-to-Agent): Enables inter-agent communication through delegation tools.
• Graphiti: Builds a corpus from URLs of official docs, supporting backends like Kuzu (local), Neo4j, or FalkorDB.
• FastMCPToolset: Provides MCP wrappers for GitLab APIs, filtered by tags for distribution.

The script initializes the graph on startup (ingesting docs if needed), creates child agents with tag-filtered tools and graph access, builds the orchestrator with delegation tools, and launches the server.

Architecture:

---
config:
  layout: dagre
---
flowchart TB
 subgraph subGraph0["Agent Capabilities"]
        C["Agent"]
        B["A2A Server - Uvicorn/FastAPI"]
        D["MCP Tools"]
        F["Agent Skills"]
  end
    C --> D & F
    A["User Query"] --> B
    B --> C
    D --> E["Platform API"]

     C:::agent
     B:::server
     A:::server
    classDef server fill:#f9f,stroke:#333
    classDef agent fill:#bbf,stroke:#333,stroke-width:2px
    style B stroke:#000000,fill:#FFD600
    style D stroke:#000000,fill:#BBDEFB
    style F fill:#BBDEFB
    style A fill:#C8E6C9
    style subGraph0 fill:#FFF9C4

This diagram shows the flow from user input to delegation, tool execution, and knowledge retrieval. The orchestrator synthesizes results from children before responding.

Breakdown

1. Pydantic-AI Integration

Pydantic-AI is the backbone for agent modeling and execution. Agents are created using the Agent class, which takes an LLM model (e.g., OpenAIChatModel), system prompt, tools/toolsets, and a name.

• Model Creation: The create_model function supports multiple providers (OpenAI, Anthropic, Google, HuggingFace) via environment variables or CLI args.
• RunContext: Used in tool functions for contextual execution.
• Agent Hierarchy: Orchestrator has delegation tools (async functions wrapping child agent.run() calls). Children have MCP toolsets and Graphiti tools.

This enables structured, type-safe agent interactions with Pydantic validation.

2. A2A (Agent-to-Agent) Framework

A2A facilitates communication between agents:

• The orchestrator is converted to an A2A app via agent.to_a2a(), defining skills (high-level capabilities per tag).
• Delegation tools are async callables named delegate_to_{tag}, allowing the orchestrator to invoke children dynamically.
• This distributes workload, with the orchestrator synthesizing outputs for a cohesive response.

3. Multiple Agents

• Orchestrator: Analyzes queries to identify domains (tags), delegates via tools, and combines results. System prompt emphasizes delegation without direct action.
• Child Agents: One per tag in TAGS list (e.g., "merge requests", "pipelines"). Each has a focused system prompt, filtered tools, and Graphiti access.
• Creation Flow: In create_orchestrator, children are instantiated in a loop, stored in a dict, and wrapped as tools for the parent.

This multi-agent setup scales by adding tags/children without refactoring the core.

4. Distribution of MCP Tools via Tags

MCP tools (from FastMCPToolset) wrap GitLab APIs. Distribution:

• Tools are tagged (e.g., "merge_requests" for merge-request-related endpoints).
• In create_child_agent, the toolset is filtered: filtered_toolset = toolset.filtered(lambda ctx, tool_def: tag in (tool_def.tags or [])).
• This ensures each child only sees relevant tools, reducing complexity and potential misuse.

Example: The "merge_request" child gets tools like merge_request creation/update, while "pipelines" gets pipelines-specific ones.

5. Corpus of Knowledge from Official Documentation (Graphiti)

• Initialization: initialize_graphiti_db creates a Graphiti instance with the chosen backend (Kuzu for local, Neo4j/FalkorDB for servers).
• Ingestion: If the graph is empty or --graphiti-force-reinit is set, it fetches and adds episodes from INITIAL_DOC_URLS (GitLab API refs, guides).
• Temporal Aspect: Graphiti's episodes preserve dates for version-aware queries.
• Access by Children:
  • For Kuzu (embedded): Custom tools ingest_to_graph and query_graph wrap Graphiti methods.
  • For servers: Uses a separate FastMCPToolset for Graphiti MCP, filtered by tag.
• Usage: Children query the graph (e.g., "Retrieve details for Merge Request API") to inform tool calls, enabling retrieval-augmented generation (RAG) over docs.

This creates a dynamic corpus, allowing agents to "understand" APIs without hardcoding.

Component Interaction Diagram

sequenceDiagram
    participant User
    participant Server as A2A Server
    participant Agent as Agent
    participant Skill as Agent Skills
    participant MCP as MCP Tools

    User->>Server: Send Query
    Server->>Agent: Invoke Agent
    Agent->>Skill: Analyze Skills Available
    Skill->>Agent: Provide Guidance on Next Steps
    Agent->>MCP: Invoke Tool
    MCP-->>Agent: Tool Response Returned
    Agent-->>Agent: Return Results Summarized
    Agent-->>Server: Final Response
    Server-->>User: Output

This sequence highlights delegation, knowledge retrieval, and tool execution.

Strengths

• Modularity & Scalability: Tags allow easy addition of domains (e.g., new GitLab modules) by extending TAGS and MCP tools.
• Knowledge-Driven Reasoning: Agent Skills keep the agent accurate and precise in actions and tasks
• Efficiency: Tool filtering prevents overload; delegation parallelizes tasks (though sequential in code, extensible to async).
• Flexibility: Supports multiple LLMs/backends via args/envs; A2A enables integration with other systems.
• Minimal Setup: Graph auto-initializes; defaults make it runnable out-of-box (assuming MCP/Graphiti servers).

Features:

• Authentication: Supports multiple authentication types including none (disabled), static (internal tokens), JWT, OAuth Proxy, OIDC Proxy, and Remote OAuth for external identity providers.
• Middleware: Includes logging, timing, rate limiting, and error handling for robust server operation.
• Eunomia Authorization: Optional policy-based authorization with embedded or remote Eunomia server integration.
• Prompts: Includes create_merge_request_prompt and query_table_prompt for AI-driven interactions.
• OIDC Token Delegation: Supports token exchange for GitLab API calls, enabling user-specific authentication via OIDC.
• OpenAPI JSON Tool Import: Import custom GitLab API Endpoints through the OpenAPI JSON generated.

Usage

API

#!/usr/bin/python

import urllib3
import os
from urllib.parse import quote_plus
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
from gitlab_api.gitlab_api import Api

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

gitlab_token = os.environ["GITLAB_TOKEN"]
postgres_username = os.environ["POSTGRES_USERNAME"]
postgres_password = os.environ["POSTGRES_PASSWORD"]
postgres_db_host = os.environ["POSTGRES_DB_HOST"]
postgres_port = os.environ["POSTGRES_PORT"]
postgres_db_name = os.environ["POSTGRES_DB_NAME"]

if __name__ == "__main__":
    print("Creating GitLab Client...")
    client = Api(
        url="http://gitlab.arpa/api/v4/",
        token=gitlab_token,
        verify=False,
    )
    print("GitLab Client Created\n\n")

    print("\nFetching User Data...")
    user_response = client.get_users(active=True, humans=True)
    print(
        f"Users ({len(user_response.data)}) Fetched - "
        f"Status: {user_response.status_code}\n"
    )

    print("\nFetching Namespace Data...")
    namespace_response = client.get_namespaces()
    print(
        f"Namespaces ({len(namespace_response.data)}) Fetched - "
        f"Status: {namespace_response.status_code}\n"
    )

    print("\nFetching Project Data...")
    project_response = client.get_nested_projects_by_group(group_id=2, per_page=100)
    print(
        f"Projects ({len(project_response.data)}) Fetched - "
        f"Status: {project_response.status_code}\n"
    )

    print("\nFetching Merge Request Data...")
    merge_request_response = client.get_group_merge_requests(
        argument="state=all", group_id=2
    )
    print(
        f"\nMerge Requests ({len(merge_request_response.data)}) Fetched - "
        f"Status: {merge_request_response.status_code}\n"
    )

    # Pipeline Jobs table
    pipeline_job_response = None
    for project in project_response.data:
        job_response = client.get_project_jobs(project_id=project.id)
        if (
            not pipeline_job_response
            and hasattr(job_response, "data")
            and len(job_response.data) > 0
        ):
            pipeline_job_response = job_response
        elif (
            pipeline_job_response
            and hasattr(job_response, "data")
            and len(job_response.data) > 0
        ):
            pipeline_job_response.data.extend(job_response.data)
            print(
                f"Pipeline Jobs ({len(getattr(pipeline_job_response, 'data', []))}) "
                f"Fetched for Project ({project.id}) - "
                f"Status: {pipeline_job_response.status_code}\n"
            )

Experimental GraphQL Support

The gitlab_gql.py module provides a GraphQL interface to interact with GitLab's GraphQL API, offering parity with the REST API functionality in gitlab_api.py. It supports queries and mutations for managing projects, branches, tags, commits, merge requests, pipelines, jobs, packages, users, memberships, releases, issues, to-dos, environments, test reports, namespaces, groups, and wikis.

Key Features

• Generic Query Execution: Use the execute_gql method to run custom GraphQL queries or mutations.
• Consistent Interface: Leverages the same Pydantic models, exceptions, and response handling as the REST API wrapper.
• Pagination Support: Handles cursor-based pagination with first and after parameters.
• Authentication: Supports Bearer token authentication, SSL verification, and proxy configuration.

Usage Example

from gitlab_api.gitlab_gql import GraphQL

# Initialize the GraphQL client
gql_api = GraphQL(url="https://gitlab.com", token="your_token")

# Fetch a project
result = gql_api.get_project(project_id="group/project")
print(result.data)

# Create a branch
result = gql_api.create_branch(project_id="group/project", branch="new-branch", ref="main")
print(result.data)

Notes

• Requires the gitlab-api[gql] package (pip install gitlab-api[gql]).
• Some features (e.g., deploy tokens, wiki attachments) are not supported in GitLab's GraphQL API and require the REST API.
• See the GitLab GraphQL API documentation for available queries and mutations.

MCP CLI

Using as an MCP Server

The MCP Server can be run in two modes: stdio (for local testing) or http (for networked access). To start the server, use the following commands:

Run in stdio mode (default):

gitlab-mcp

Run in HTTP mode:

gitlab-mcp --transport http --host 0.0.0.0 --port 8012

CLI Configuration

Run the MCP server with custom options:

gitlab-mcp --transport http --host 0.0.0.0 --port 8002 \
  --auth-type jwt \
  --token-jwks-uri "https://example.com/.well-known/jwks.json" \
  --token-issuer "https://example.com" \
  --token-audience "gitlab-mcp" \
  --eunomia-type embedded \
  --eunomia-policy-file "policies.json"

Available CLI options:

• --transport: Transport method (stdio, http, sse) [default: stdio]
• --host: Host address for HTTP/SSE transport [default: 0.0.0.0]
• --port: Port number for HTTP/SSE transport [default: 8002]
• --auth-type: Authentication type (none, static, jwt, oauth-proxy, oidc-proxy, remote-oauth) [default: none]
• --token-jwks-uri: JWKS URI for JWT verification
• --token-issuer: Issuer for JWT verification
• --token-audience: Audience for JWT verification
• --oauth-upstream-auth-endpoint: Upstream authorization endpoint for OAuth proxy
• --oauth-upstream-token-endpoint: Upstream token endpoint for OAuth proxy
• --oauth-upstream-client-id: Upstream client ID for OAuth proxy
• --oauth-upstream-client-secret: Upstream client secret for OAuth proxy
• --oauth-base-url: Base URL for OAuth proxy
• --oidc-config-url: OIDC configuration URL
• --oidc-client-id: OIDC client ID
• --oidc-client-secret: OIDC client secret
• --oidc-base-url: Base URL for OIDC proxy
• --remote-auth-servers: Comma-separated list of authorization servers for remote OAuth
• --remote-base-url: Base URL for remote OAuth
• --allowed-client-redirect-uris: Comma-separated list of allowed client redirect URIs
• --eunomia-type: Eunomia authorization type (none, embedded, remote) [default: none]
• --eunomia-policy-file: Policy file for embedded Eunomia [default: mcp_policies.json]
• --eunomia-remote-url: URL for remote Eunomia server

Agent-to-Agent (A2A) Server

The A2A Server exposes a multi-agent system where a parent orchestrator delegates tasks to specialized child agents based on GitLab tags.

Endpoints

• Web UI: http://localhost:8000/ (if enabled)
• A2A: http://localhost:8000/a2a (Discovery: /a2a/.well-known/agent.json)
• AG-UI: http://localhost:8000/ag-ui (POST)

Run the A2A Server:

gitlab-agent --provider openai --model-id qwen3:4b

A2A CLI Configuration

Run using Docker

You can run either the MCP server or the A2A server using the same Docker image.

Run MCP Server:

docker run -d -p 8000:8000 --name gitlab-mcp gitlab-api:latest gitlab-mcp --transport http

Run A2A Server:

docker run -d -p 9000:9000 --name gitlab-agent gitlab-api:latest gitlab-agent \
  --provider openai \
  --model-id qwen3:4b \
  --mcp-url http://host.docker.internal:8000/mcp

AI Prompt Examples

Prompt: Get me the details of my GitLab project with ID 420.

Response:

Here are the details for your GitLab project:

Project Name: Docker Registry
Project ID: 420
Namespace: Homelab
Visibility: Internal
Created: November 13, 1999
Default Branch: main
Last Activity: August 20, 2025
Web URL: http://gitlab.arpa/homelab/docker-registry

This project is configured with container registry capabilities
and supports CI/CD pipelines, merge requests, and issue tracking.
It is currently active with no open issues and follows
the default branch strategy for its workflow.

Prompt: Run the GitLab pipeline for this project ID 133 on the main branch.

Response:

The pipeline has been successfully created for the project ID 133 on the main reference. Here are the details:

Pipeline ID: 20601
Reference: main
SHA: asidfaskdjvalksdjv
Status: Created
Web URL:

Created At: 2025-08-27T02:49:20.068Z
The pipeline is now queued and will start executing soon. Let me know if you'd like further details or actions!

Prompt: Create a branch called "test" from the main branch in this GitLab project with ID 133.

Response:

The branch test has been successfully created from the main branch in the project with ID 133.

Branch Details:
Name: test
URL:

Commit:
Short ID: 1c3775ac
Message: "Add adguard."
Author: KnucklesSG1
Committed Date: August 25, 2025, at 05:03:01 (UTC-05:00)
This branch is not protected, and it is not set as the default branch.
The branch is currently unmerged and can be pushed to by authorized users.

Let me know if you'd like further actions (e.g., merging, pushing changes)!

Prompt: Create a merge request for project 133 from the test branch to the main branch with a title of "This is a merge request by Qwen3" and a description of "This is a description populated by Qwen3 LLM".

Response:

The merge request has been successfully created with the following details:

Title: This is a merge request by Qwen3
Description: This is a description populated by Qwen3 LLM
Source Branch: test
Target Branch: main
Project: homelab/containers/services/project
Merge Request URL:

Status: Opened
Created At: 2025-08-27T03:15:51.520000Z
The merge request is currently in the "preparing" state and is ready for review. Let me know if you'd like further actions, such as assigning reviewers or approving the merge! 😊

Deploy MCP Server as a Service

The MCP server can be deployed using Docker, with configurable authentication, middleware, and Eunomia authorization.

Using Docker Run

docker pull knucklessg1/gitlab:latest

docker run -d \
  --name gitlab-mcp \
  -p 8004:8004 \
  -e HOST=0.0.0.0 \
  -e PORT=8004 \
  -e TRANSPORT=http \
  -e AUTH_TYPE=none \
  -e EUNOMIA_TYPE=none \
  knucklessg1/gitlab:latest

For advanced authentication (e.g., JWT, OAuth Proxy, OIDC Proxy, Remote OAuth) or Eunomia, add the relevant environment variables:

docker run -d \
  --name gitlab-mcp \
  -p 8004:8004 \
  -e HOST=0.0.0.0 \
  -e PORT=8004 \
  -e TRANSPORT=http \
  -e AUTH_TYPE=oidc-proxy \
  -e OIDC_CONFIG_URL=https://provider.com/.well-known/openid-configuration \
  -e OIDC_CLIENT_ID=your-client-id \
  -e OIDC_CLIENT_SECRET=your-client-secret \
  -e OIDC_BASE_URL=https://your-server.com \
  -e ALLOWED_CLIENT_REDIRECT_URIS=http://localhost:*,https://*.example.com/* \
  -e EUNOMIA_TYPE=embedded \
  -e EUNOMIA_POLICY_FILE=/app/mcp_policies.json \
  knucklessg1/gitlab:latest

Using Docker Compose

Create a docker-compose.yml file:

services:
  gitlab-mcp:
    image: knucklessg1/gitlab:latest
    environment:
      - HOST=0.0.0.0
      - PORT=8004
      - TRANSPORT=http
      - AUTH_TYPE=none
      - EUNOMIA_TYPE=none
    ports:
      - 8004:8004

For advanced setups with authentication and Eunomia:

services:
  gitlab-mcp:
    image: knucklessg1/gitlab:latest
    environment:
      - HOST=0.0.0.0
      - PORT=8004
      - TRANSPORT=http
      - AUTH_TYPE=oidc-proxy
      - OIDC_CONFIG_URL=https://provider.com/.well-known/openid-configuration
      - OIDC_CLIENT_ID=your-client-id
      - OIDC_CLIENT_SECRET=your-client-secret
      - OIDC_BASE_URL=https://your-server.com
      - ALLOWED_CLIENT_REDIRECT_URIS=http://localhost:*,https://*.example.com/*
      - EUNOMIA_TYPE=embedded
      - EUNOMIA_POLICY_FILE=/app/mcp_policies.json
    ports:
      - 8004:8004
    volumes:
      - ./mcp_policies.json:/app/mcp_policies.json

Run the service:

docker-compose up -d

Configure mcp.json for AI Integration

Recommended: Store secrets in environment variables with lookup in JSON file.

For Testing Only: Plain text storage will also work, although not recommended.

{
  "mcpServers": {
    "gitlab": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "gitlab-api",
        "gitlab-mcp",
        "--transport",
        "http",
        "--host",
        "0.0.0.0",
        "--port",
        "8002",
        "--auth-type",
        "jwt",
        "--token-jwks-uri",
        "https://example.com/.well-known/jwks.json",
        "--token-issuer",
        "https://example.com",
        "--token-audience",
        "gitlab-mcp",
        "--eunomia-type",
        "embedded",
        "--eunomia-policy-file",
        "mcp_policies.json"
      ],
      "env": {
        "GITLAB_INSTANCE": "https://gitlab.com/api/v4/",
        "GITLAB_ACCESS_TOKEN": "glpat-askdfalskdvjas",
        "GITLAB_VERIFY": "True"
      },
      "timeout": 200000
    }
  }
}

Install Python Package

Install Python Package

python -m pip install --upgrade gitlab-api

or

uv pip install --upgrade gitlab-api

Test

pre-commit check

pre-commit run --all-files

pytest

python -m pip install -r test-requirements.txt
pytest ./test/test_gitlab_models.py

Full pytests

rm -rf ./dist/* \
&& python setup.py bdist_wheel --universal \
&& python -m pip uninstall gitlab-api -y \
&& python -m pip install ./dist/*.whl \
&& pytest -vv ./test/test_gitlab_models.py

Validate MCP Server

npx @modelcontextprotocol/inspector gitlab-mcp

Repository Owners: