Skip to main content
Glama
nunolima

GitLab Documentation MCP Server

by nunolima
OverviewSchemaRelated ServersScoreDiscussions
Remote

GitLab Documentation MCP Server

A Model Context Protocol (MCP) server that provides searchable access to GitLab's official documentation. This server indexes markdown documentation from multiple GitLab OSS repositories and makes it available for AI assistants and other MCP clients.

Features

  • Full-text search across GitLab documentation using SQLite FTS5

  • Version-specific docs - Build for any GitLab version (e.g., 18.7.2) or latest

  • Multiple repositories indexed:

    • GitLab CE/EE (main application)

    • GitLab Runner (CI/CD runner)

    • Omnibus GitLab (installation packages)

    • Gitaly (Git RPC service)

    • GitLab Pages (static sites)

    • GitLab Agent (Kubernetes integration, includes KAS)

  • Optimized Docker image - Uses sparse checkout and filters to minimize size

Related MCP server: docs-mcp-server

Building the Docker Image

Find the GitLab Version

Look for the latest patch version for your desired GitLab release:

Build for Specific Version

# Set the GitLab version you want (use full patch version)
GITLAB_VERSION=18.7.2

# Build the image
GITLAB_MINOR=$(echo $GITLAB_VERSION | cut -d. -f1,2)
docker build -f docker/Dockerfile --build-arg GITLAB_VERSION=$GITLAB_VERSION \
    -t gitlab-docs-mcp:$GITLAB_VERSION \
    -t mcp/gitlab-docs-mcp:$GITLAB_VERSION \
    -t gitlab-docs-mcp:$GITLAB_MINOR \
    -t mcp/gitlab-docs-mcp:$GITLAB_MINOR .

# Verify the images were created
echo "\nCreated images:"
docker images | grep gitlab-docs-mcp

# Test the image - initialize and list tools
echo "\nTesting MCP server initialization:"
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' | \
  docker run -i --rm mcp/gitlab-docs-mcp:$GITLAB_VERSION | jq .

echo "\nListing available tools:"
(echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'; \
 echo '{"jsonrpc":"2.0","id":2,"method":"tools/list"}') | \
  docker run -i --rm mcp/gitlab-docs-mcp:$GITLAB_VERSION 2>/dev/null | tail -1 | jq .

Build for Latest (Main Branch)

docker build -f docker/Dockerfile \
    -t gitlab-docs-mcp:latest \
    -t mcp/gitlab-docs-mcp:latest .

# Verify the images were created
echo "\nCreated images:"
docker images | grep gitlab-docs-mcp

# Test the image - initialize and list tools
echo "\nTesting MCP server initialization:"
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' | \
  docker run -i --rm mcp/gitlab-docs-mcp:latest | head -20
echo "\nListing available tools:"
(echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'; \
 echo '{"jsonrpc":"2.0","id":2,"method":"tools/list"}') | \
  docker run -i --rm mcp/gitlab-docs-mcp:latest 2>/dev/null | tail -1 | jq .```

## Installation

This server is published to the [MCP Community Registry](https://registry.modelcontextprotocol.io/v0/servers?search=io.github.nunolima/gitlab-docs-mcp).

### Prerequisites

- Docker installed and running
- MCP-compatible client (Claude Desktop, Cline, Cursor, etc.)

### Setup Instructions

#### Claude Desktop

1. **Locate your config file**:
   - macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
   - Windows: `%APPDATA%\Claude\claude_desktop_config.json`
   - Linux: `~/.config/Claude/claude_desktop_config.json`

2. **Add the server configuration**:
   ```json
   {
     "mcpServers": {
       "gitlab-docs": {
         "command": "docker",
         "args": ["run", "-i", "--rm", "nunolima/gitlab-docs-mcp:18.7"]
       }
     }
   }

  1. Restart Claude Desktop - The server will appear in the MCP tools menu (๐Ÿ”Œ icon)

Cline (VS Code Extension)

  1. Open Cline settings in VS Code

  2. Navigate to MCP Servers section

  3. Add this configuration:

    {
  "mcpServers": {
    "gitlab-docs": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "nunolima/gitlab-docs-mcp:18.7"]
    }
  }
}

  4. Reload VS Code window

Cursor

  1. Open Cursor settings

  2. Go to Features โ†’ Model Context Protocol

  3. Add the server configuration:

    {
  "mcpServers": {
    "gitlab-docs": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "nunolima/gitlab-docs-mcp:18.7"]
    }
  }
}

Version Selection

Choose the version that matches your GitLab deployment:

// For GitLab 18.7.x
"args": ["run", "-i", "--rm", "nunolima/gitlab-docs-mcp:18.7"]

// For latest GitLab version
"args": ["run", "-i", "--rm", "nunolima/gitlab-docs-mcp:latest"]

Verification

After setup, verify the server is working:

  1. In Claude Desktop: Look for the ๐Ÿ”Œ icon - you should see "gitlab-docs" listed

  2. Test a query: Ask Claude to search GitLab documentation, e.g., "Search GitLab docs for CI/CD pipeline configuration"

  3. Check Docker: Run docker ps -a after making a query to see if the container ran

An good test AI request message is: Using only the "gitlab-docs-mcp" mcp tools as source, what is the latest x.y.z GitLab version covered in the GitLab upgrade notes (doc/update/versions/)?

Troubleshooting

Server not appearing in client:

  • Ensure Docker is running: docker info

  • Check config file JSON is valid (no trailing commas, proper quotes)

  • Restart your MCP client completely

"Cannot connect to Docker daemon" error:

  • Start Docker Desktop

  • Verify Docker is accessible: docker ps

Old documentation version:

Available Tools

Once connected, the server provides these tools (MCP Python SDK v2, structured outputs):

  • search_docs: Full-text search across all GitLab documentation (returns paths, titles, repos)

  • get_doc: Retrieve a specific document by exact path from search results

  • search_and_fetch: Search and return full markdown for each hit in one call

Resources

  • docs://repos: Indexed repository keys

  • docs://{+path}: Full markdown for an indexed document path

Example Queries

Try asking your AI assistant:

  • "Search GitLab docs for how to set up GitLab Runner with Docker"

  • "Find documentation about GitLab CI/CD pipeline syntax"

  • "What does the GitLab documentation say about backup and restore?"

  • "Search for GitLab Pages custom domain configuration"

How It Works

  1. Build time: Clones doc folders from GitLab repositories using sparse checkout

  2. Indexing: Parses markdown files and builds an SQLite FTS5 search index

  3. Runtime: MCP server provides search tools to query the indexed documentation

Versioning Strategy

  • Main GitLab repo: Uses full version tag (e.g., v18.7.2-ee)

  • Omnibus GitLab: Uses full version with +ee suffix (e.g., 18.7.2+ee.0)

  • Other repositories: Use major.minor.0 version (e.g., v18.7.0)

    • This uses the first stable release (.0) for each major.minor version

    • Example: Building GitLab 18.7.2 will use Runner/Gitaly/Pages/Agent v18.7.0

Development

Project Structure

python/gitlab-docs-mcp/
โ”œโ”€โ”€ docker/
โ”‚   โ””โ”€โ”€ Dockerfile         # Main Dockerfile with version support
โ”œโ”€โ”€ indexer/
โ”‚   โ””โ”€โ”€ build_index.py     # Builds search index from markdown files
โ”œโ”€โ”€ server/
โ”‚   โ””โ”€โ”€ main.py           # MCP server implementation
โ”œโ”€โ”€ data/
โ”‚   โ””โ”€โ”€ docs.db           # SQLite FTS5 database (generated)
โ””โ”€โ”€ repos/                # Cloned documentation (generated)

Local Development

# Install dependencies
pip install -r requirements.txt

# Clone repos manually for testing
# (or let Docker handle it)

# Build index
python indexer/build_index.py

# Run server (stdio)
python -m server.main

Integration tests (curl + jq)

test.sh starts the Docker image with Streamable HTTP and validates discover, tools, and resources against MCP protocol 2026-07-28:

# Rebuild image first, then:
./test.sh 19.0.5

# Or against an already-running HTTP server:
MCP_TRANSPORT=streamable-http MCP_HOST=0.0.0.0 MCP_PORT=8000 python -m server.main
MCP_BASE_URL=http://127.0.0.1:8000/mcp ./test.sh

License

MIT License - Copyright (c) 2026 Nuno Lima

This project indexes documentation from GitLab's open source repositories. See individual repository licenses for details.

Acknowledgments

Development of this project was supported by OLX, which provided access to AI-assisted development tools.

Available Tools

3 tools
get_docGet GitLab docA
Read-onlyIdempotent

Fetch the full markdown content of a single documentation page by path.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesExact document path from search results.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pathYes
repoYes
titleYes
contentYesFull markdown body of the document.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and idempotent; the description adds that the response is the page's full Markdown content rather than a summary or search snippet. This clarifies output granularity and format beyond what the safety annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the key action and resource, with no filler or redundant explanation. Every word contributes to selecting or invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-required-parameter read tool with an output schema and safety annotations, the description plus schema fully covers what an agent needs: what to fetch, how to identify the page, and that it is read-only/idempotent. No missing prerequisite or postcondition creates ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole parameter, path, is already described as the exact document path from search results. The description only repeats 'by path' and does not add formatting, encoding, or alternate-source guidance, so it stays at the baseline for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('fetch'), resource ('full markdown content of a single documentation page'), and method ('by path'). This clearly distinguishes it from the search-oriented siblings search_docs and search_and_fetch, which find or combine docs rather than retrieving one known page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description and path parameter make the usage context clear: call this when you already have the exact document path, which the schema says comes from search results. It does not explicitly name when-not-to-use conditions or alternatives, but the intended flow is easily inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_and_fetchSearch then fetch GitLab docsA
Read-onlyIdempotent

Search documentation and return full markdown for each hit in one call.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum documents to search and fetch.
queryYesFull-text search query (SQLite FTS5).

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of documents returned with content.
queryYes
documentsYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only and idempotent behavior, and the description adds useful context about the combined search-and-fetch outcome and that full markdown is returned for each hit. It does not discuss potential response size, but that is minor given the annotations and output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that front-loads the action and outcome with no filler. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with rich schema documentation, read-only/idempotent annotations, an output schema, and clear combined behavior, the description is complete. An agent has enough information to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents query and limit. The description's phrase 'full markdown for each hit' slightly reinforces the limit's behavior, but it adds no new parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb (search) and resource (documentation), and the key distinctive outcome: returns full markdown for each hit in one call. This directly differentiates it from siblings like search_docs or get_doc, which would require separate calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'in one call' implies it should be used when both searching and retrieving full content are needed, but it does not explicitly name alternatives or state when not to use it. Usage context is inferred from the behavior rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_docsSearch GitLab docsB
Read-onlyIdempotent

Search indexed GitLab documentation and return matching paths and titles.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum hits to return.
queryYesFull-text search query (SQLite FTS5).

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of hits returned.
queryYes
resultsYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and repeatability. The description adds that the search operates over 'indexed' documentation and returns only paths and titles, which is useful but does not go beyond what the annotations and output schema already convey. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that names the action, the resource, and the result shape with no wasted words. It is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple schema, full parameter descriptions, output schema presence, and annotations covering read-only/idempotent behavior, the description is largely sufficient for invoking the tool correctly. The main missing piece is sibling differentiation, which prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both 'query' and 'limit' already documented in the input schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Search') and resource ('indexed GitLab documentation'), and specifies the return type ('matching paths and titles'). It does not explicitly contrast itself with siblings like get_doc or search_and_fetch, so it slightly falls short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when searching docs is needed) but provides no guidance on when to prefer it over the sibling alternatives, nor any exclusion criteria. With siblings named get_doc and search_and_fetch, the absence of routing advice is a notable gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation4/5

search_docs and get_doc are clearly distinct, with one returning metadata and the other full content. search_and_fetch overlaps with both by combining them, but its purpose as a convenience method is clear enough to avoid real confusion.

Naming Consistency4/5

search_docs and get_doc follow a consistent verb_noun pattern. search_and_fetch breaks the pattern slightly by combining two verbs with 'and', but the overall naming style remains predictable and readable.

Tool Count5/5

Three tools is appropriate for a documentation-focused server: one to search, one to retrieve a single document, and one combined operation. Each tool has a distinct, useful purpose with no redundancy.

Completeness4/5

The core documentation workflow of searching and fetching content is fully covered. A minor gap is the lack of browsing or listing documentation paths without a search query, but agents can work around this using search_docs.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • docs-mcp-server

    arabold
    A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol (MCP) server that scrapes, indexes, and searches documentation for third-party software libraries and packages, supporting versioning and hybrid search.
    3,225
    1,674
    MIT

  • GitLab MCP Server

    ZephyrDeng
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    A Model Context Protocol server that enables AI assistants to interact with GitLab repositories, allowing tasks like managing merge requests, searching projects, and creating comments through RESTful API integration.
    19
    2

  • gitlab-mcp

    EllGree
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for interacting with GitLab API, supporting both self-hosted instances and gitlab.com. Provides tools for managing issues, merge requests, code review, pipelines, milestones, releases, search, and file access.
    302
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nunolima/gitlab-docs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server