Skip to main content
Glama

Repository

gitlab_repository
Destructive

Browse and manage GitLab repository content: files, commits, diffs, blame, compare branches, contributors, archives, changelogs, submodules, and markdown. Perform file CRUD and commit operations with optimistic concurrency control.

Instructions

Example: {"action":"archive","params":{...}} For the params schema of any action, read the MCP resource gitlab://schema/meta/gitlab_repository/.

Browse and manage GitLab repository content: file tree, read/write/delete files, commits, diffs, cherry-pick, revert, blame, compare branches, contributors, archives, changelogs, submodules, render markdown, and commit discussions. File delete is destructive. When to use: file/commit operations, diffs, blame, compare, archives, submodules, markdown rendering. NOT for: branch CRUD (use gitlab_branch), tag CRUD (use gitlab_tag).

Behavior:

  • Idempotent reads: tree, blob, raw_blob, archive, compare, merge_base, contributors, file_get/raw/metadata/raw_metadata/blame, list_submodules, read_submodule_file, file_history, commit_list/get/diff/refs/comments/merge_requests/statuses/signature, commit_discussion_list/get, markdown_render, changelog_generate.

  • file_create / file_update / file_delete / commit_create / commit_cherry_pick / commit_revert / update_submodule / changelog_add are NON-idempotent: when preconditions are satisfied each call produces a new commit SHA; otherwise they fail (e.g. 400 on conflict, 409 on stale last_commit_id). Use last_commit_id on file_update/file_delete for optimistic-concurrency safety.

  • commit_status_set is idempotent per (sha, name, ref); commit_comment_create / commit_discussion_create / commit_discussion_add_note append rather than replace. commit_discussion_update_note replaces the existing note body.

  • Side effects: any commit-producing action triggers webhooks, CI pipelines, and protected-branch / push-rule checks; archive returns large binary payloads (base64).

  • File delete is destructive at the working-tree level but git history is preserved.

Returns: JSON with resource data. Lists include pagination (page, per_page, total, next_page). Void actions return confirmation. Errors: 404 (hint: confirm project_id, ref/sha, and file_path — paths are URL-encoded), 403 (hint: file_create/file_update/file_delete and commit_* require Developer+; protected branches may need Maintainer+), 400 (hint: file_update/file_delete accept last_commit_id for optimistic concurrency; commit_create needs at least one entry in actions).

Param conventions: * = required. Most actions need project_id*. List actions accept page, per_page.

Repository browsing:

  • tree: project_id*, path, ref, recursive

  • compare: project_id*, from*, to*, straight

  • contributors: project_id*, order_by (name/email/commits), sort

  • merge_base: project_id*, refs* (array of 2+ branch/tag/SHA)

  • blob / raw_blob: project_id*, sha*

  • archive: project_id*, sha, format (tar.gz/zip/tar.bz2), path

Changelogs:

  • changelog_add: project_id*, version*, branch, config_file, file, from, to, message, trailer

  • changelog_generate: project_id*, version*, config_file, from, to, trailer

Commits:

  • commit_create: project_id*, branch*, commit_message*, actions* (array of {action: create/update/delete/move, file_path, content, previous_path}), start_branch, author_email, author_name

  • commit_list: project_id*, ref_name, since, until, path, author, with_stats

  • file_history: alias for commit_list filtered by path* — list commits modifying a specific file

  • commit_get: project_id*, sha*

  • commit_diff: project_id*, sha*

  • commit_refs: project_id*, sha*, type (branch/tag/all)

  • commit_comments / commit_merge_requests: project_id*, sha*

  • commit_comment_create: project_id*, sha*, note*, path, line, line_type (new/old)

  • commit_statuses: project_id*, sha*, ref, stage, name, pipeline_id, all

  • commit_status_set: project_id*, sha*, state* (pending/running/success/failed/canceled), ref, name, context, target_url, description, coverage, pipeline_id

  • commit_cherry_pick: project_id*, sha*, branch*, dry_run, message

  • commit_revert: project_id*, sha*, branch*

  • commit_signature: project_id*, sha*

Files:

  • file_get / file_raw / file_metadata / file_raw_metadata / file_blame: project_id*, file_path*, ref. Blame also accepts range_start, range_end.

    • file_metadata: HEAD-style metadata for the file content endpoint (size, encoding, content_sha256, blob_id, last_commit_id, ref).

    • file_raw_metadata: HEAD-style metadata for the raw file endpoint (size, content_type, ref) — useful to size-check before downloading via file_raw.

  • file_create: project_id*, file_path*, branch*, commit_message*, content, start_branch, encoding (text/base64), author_email, author_name, execute_filemode

  • file_update: project_id*, file_path*, branch*, commit_message*, content, start_branch, encoding, author_email, author_name, last_commit_id, execute_filemode

  • file_delete: project_id*, file_path*, branch*, commit_message*, start_branch, author_email, author_name, last_commit_id

Submodules:

  • update_submodule: project_id*, submodule* (URL-encoded path), branch*, commit_sha*, commit_message

  • list_submodules: project_id*, ref

  • read_submodule_file: project_id*, submodule_path*, file_path*, ref

Markdown:

  • markdown_render: text*, gfm, project (path for resolving references)

Commit discussions:

  • commit_discussion_list: project_id*, commit_id*

  • commit_discussion_get: project_id*, commit_id*, discussion_id*

  • commit_discussion_create: project_id*, commit_id*, body*, position

  • commit_discussion_add_note: project_id*, commit_id*, discussion_id*, body*

  • commit_discussion_update_note: project_id*, commit_id*, discussion_id*, note_id*, body*

  • commit_discussion_delete_note: project_id*, commit_id*, discussion_id*, note_id*

See also: gitlab_branch, gitlab_tag, gitlab_project, gitlab_merge_request

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform. Pick exactly one of the values in `enum`. Each action expects its own `params` object — see the tool description for the per-action parameter list.
paramsNoAction-specific parameters as a JSON object. Required and optional fields differ per action; consult this tool's description for the chosen action. Send only the fields documented for that action — unknown keys are rejected with a validation error (only reserved meta keys like `confirm` are stripped before validation). For the JSON Schema of a specific action's `params`, read the MCP resource `gitlab://schema/meta/{tool}/{action}` (replace placeholders with the tool name and the chosen action).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.
Behavior5/5

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

Separate 'Behavior' section categorizes idempotent vs. non-idempotent actions, explains side effects (webhooks, CI pipelines), error codes with hints, and param conventions. Annotations (destructiveHint, openWorldHint) are consistent and description adds depth like file delete destructive but history preserved.

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

Conciseness4/5

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

Very long but well-structured with sections (Behavior, Returns, Errors, Param conventions, action groups). Front-loaded with summary. Length is justified by tool complexity; could be slightly more concise.

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?

Covers all actions, parameters, error handling, pagination, return types, and side effects. Output schema exists and description adds return format details. Complete for a complex multi-action tool.

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

Parameters5/5

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

Schema coverage is 100% but description provides extensive per-action parameter details beyond schema, including required/optional fields, defaults, and constraints. Adds value by listing specific parameters for each of the 40+ actions.

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 clearly states it browses and manages GitLab repository content with specific operations (files, commits, diffs, etc.). It distinguishes from sibling tools gitlab_branch and gitlab_tag by explicitly saying what it is NOT for.

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

Usage Guidelines5/5

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

Explicit 'When to use' and 'NOT for' sections, naming sibling tools for branch and tag operations. Provides clear guidance on appropriate context.

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

Install Server

Other Tools

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/jmrplens/gitlab-mcp-server'

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