Skip to main content
Glama

Project

gitlab_project
Destructive

Manage GitLab projects: create, fork, transfer, archive, delete; configure visibility, members, webhooks, integrations, approval rules, mirrors, badges, labels, milestones; uploads, imports/exports, housekeeping. For project-level settings.

Instructions

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

Manage GitLab projects end-to-end: lifecycle (create/fork/transfer/archive/delete), visibility & access (members, share, approval rules, integrations, webhooks), and advanced features (mirrors, Pages, badges, boards, labels, milestones, uploads, avatars, import/export, housekeeping). Delete, unpublish, force-push and *_delete actions are destructive. When to use: project-level configuration and metadata. NOT for: file content/commits (use gitlab_repository), branches (gitlab_branch), wiki pages (gitlab_wiki), issues (gitlab_issue), MRs (gitlab_merge_request).

Behavior:

  • Idempotent reads: every get/list/_get/_list action plus badge_preview, languages, repository_storage_get, statistics_get.

  • Idempotent mutations: update / *_update / edit / star / unstar / archive / unarchive / hook_set. NON-idempotent: create, fork, *_create, hook_add, hook_test — each invocation queues a new webhook delivery.

  • Side effects: hook_add/edit/test trigger webhook deliveries; member_add/share/edit and integration_set_* notify users; transfer relocates the project and members; export_schedule / import_from_file / start_mirroring / start_housekeeping queue long-running async work (poll *_status); upload_avatar / upload mutate storage.

  • Destructive: delete (unless restore window applies), *_delete (hook/label/milestone/badge/board/integration/approval_rule/mirror/upload/pages_domain/board_list), pages_unpublish, mirror_force_push, delete_shared_group, delete_fork_relation. archive is reversible via unarchive.

Returns: list/*_list actions return paginated arrays {page, per_page, total, next_page}. CRUD/get/configure/upload actions return the resource object — including label_subscribe (returns the updated label). Pure-mutation actions (delete, delete, mirror_force_push, start, *_promote, label_unsubscribe) return {success, message}. Errors: 404 (hint: project_id may be a numeric ID or URL-encoded path like 'group%2Frepo'), 403 (hint: most mutations require Maintainer+; settings/transfers require Owner; instance-level actions require admin), 400 (hint: visibility ∈ private/internal/public; merge_method ∈ merge/rebase_merge/ff; namespace_id must be writable by the caller).

Param conventions: * = required. Most actions need project_id* (numeric ID or URL-encoded path like 'group/repo'). List actions accept page, per_page. Access levels: 10=Guest, 20=Reporter, 30=Developer, 40=Maintainer, 50=Owner.

Project CRUD:

  • create: name*, namespace_id, description, visibility (private/internal/public), initialize_with_readme, default_branch, path, topics, merge_method (merge/rebase_merge/ff), squash_option (never/always/default_on/default_off), ci_config_path, feature toggles (issues/merge_requests/wiki/jobs/lfs/request_access_enabled)

  • get: project_id*

  • list: owned, search, visibility, archived, order_by, sort, topic, simple, min_access_level, last_activity_after/before, starred, membership, search_namespaces, statistics, include_pending_delete, include_hidden

  • update: project_id*, name, description, visibility, default_branch, merge_method, topics, squash_option, merge_commit_template, squash_commit_template, merge_pipelines_enabled, merge_trains_enabled, approvals_before_merge, feature toggles

  • delete: project_id*, permanently_remove, full_path (required when permanently_remove=true). Delayed deletion by default; permanently_remove bypasses it

  • restore: project_id*

Project actions:

  • fork: project_id*, name, path, namespace_id, namespace_path, visibility, branches, mr_default_target_self

  • star / unstar / archive / unarchive / languages: project_id*

  • transfer: project_id*, namespace* (ID or path)

  • list_forks: project_id*, owned, search, visibility, order_by, sort

  • create_fork_relation: project_id*, forked_from_id*

  • delete_fork_relation: project_id*

Users and groups:

  • list_user_projects: user_id* (ID or username), search, visibility, archived, order_by, sort, simple

  • list_users / list_starrers: project_id*, search

  • list_groups: project_id*, search, with_shared, shared_visible_only, skip_groups, shared_min_access_level

  • share_with_group: project_id*, group_id*, group_access* (10-40), expires_at

  • delete_shared_group: project_id*, group_id*

  • list_invited_groups: project_id*, search, min_access_level

  • list_user_contributed / list_user_starred: user_id*, search, visibility, archived, order_by, sort, simple

Members (member_*):

  • members: project_id*, query (filter name/username)

  • member_get / member_inherited: project_id*, user_id*

  • member_add: project_id*, user_id or username*, access_level* (10-50), expires_at, member_role_id

  • member_edit: project_id*, user_id*, access_level*, expires_at, member_role_id

  • member_delete: project_id*, user_id*

Webhooks (hook_*) — event booleans: push/tag_push/issues/merge_requests/note/job/pipeline/wiki_page/deployment/releases/emoji:

  • hook_list: project_id*

  • hook_get / hook_delete: project_id*, hook_id*

  • hook_add: project_id*, url*, name, description, token, event booleans, enable_ssl_verification, push_events_branch_filter, custom_webhook_template, branch_filter_strategy

  • hook_edit: project_id*, hook_id*, same params as hook_add

  • hook_test: project_id*, hook_id*, event* (e.g. push_events)

  • hook_set_custom_header / hook_set_url_variable: project_id*, hook_id*, key*, value*

  • hook_delete_custom_header / hook_delete_url_variable: project_id*, hook_id*, key*

Labels (label_*):

  • label_list: project_id*, search, with_counts, include_ancestor_groups

  • label_get / label_delete / label_subscribe / label_unsubscribe / label_promote: project_id*, label_id*

  • label_create: project_id*, name*, color* (hex), description, priority

  • label_update: project_id*, label_id*, new_name, color, description, priority

Milestones (milestone_*):

  • milestone_list: project_id*, state (active/closed), title, search, include_ancestors

  • milestone_get / milestone_delete: project_id*, milestone_iid*

  • milestone_create: project_id*, title*, description, start_date, due_date

  • milestone_update: project_id*, milestone_iid*, title, description, start_date, due_date, state_event (activate/close)

  • milestone_issues / milestone_merge_requests: project_id*, milestone_iid*

Badges (badge_*):

  • badge_list: project_id*, name

  • badge_get / badge_delete: project_id*, badge_id*

  • badge_add / badge_preview: project_id*, link_url*, image_url*, name

  • badge_edit: project_id*, badge_id*, link_url, image_url, name

Boards (board_*):

  • board_list: project_id*

  • board_get / board_delete: project_id*, board_id*

  • board_create: project_id*, name*

  • board_update: project_id*, board_id*, name, assignee_id, milestone_id, labels, weight, hide_backlog_list, hide_closed_list

  • board_list_list: project_id*, board_id*

  • board_list_get / board_list_delete: project_id*, board_id*, list_id*

  • board_list_create: project_id*, board_id*, label_id

  • board_list_update: project_id*, board_id*, list_id*, position

Integrations (integration_*):

  • integration_list: project_id*

  • integration_get / integration_delete: project_id*, slug* (e.g. jira, slack, discord, datadog, jenkins, mattermost, telegram)

  • integration_set_jira: project_id*, url*, username, password, active, api_url, jira_auth_type, jira_issue_prefix, commit_events, merge_requests_events, issues_enabled, project_keys

Uploads:

  • upload: project_id*, filename*, file_path or content_base64 (one required). Returns Markdown embed

  • upload_list: project_id*

  • upload_delete: project_id*, upload_id*

Import/Export:

  • export_schedule / export_status / export_download: project_id*

  • import_from_file: file_path or content_base64 (one required), namespace, name, path, overwrite

  • import_status: project_id*

Pages (pages_*):

  • pages_get / pages_unpublish: project_id*

  • pages_update: project_id*, pages_https_only, pages_access_level

  • pages_domain_list_all: (admin only)

  • pages_domain_list: project_id*

  • pages_domain_get / pages_domain_delete: project_id*, domain*

  • pages_domain_create / pages_domain_update: project_id*, domain*, certificate, key

Avatars:

  • upload_avatar: project_id*, filename*, content_base64*

  • download_avatar: project_id*

Approval rules (approval_*):

  • approval_config_get: project_id*

  • approval_config_change: project_id*, approvals_before_merge, reset_approvals_on_push, merge_requests_author_approval, merge_requests_disable_committers_approval, require_password_to_approve

  • approval_rule_list: project_id*

  • approval_rule_get / approval_rule_delete: project_id*, rule_id*

  • approval_rule_create: project_id*, name*, approvals_required*, rule_type, user_ids, group_ids, protected_branch_ids, usernames, applies_to_all_protected_branches

  • approval_rule_update: project_id*, rule_id*, name, approvals_required, user_ids, group_ids, protected_branch_ids, usernames

Pull mirroring:

  • pull_mirror_get: project_id*

  • pull_mirror_configure: project_id*, enabled, url, auth_user, auth_password, mirror_branch_regex, mirror_trigger_builds, only_mirror_protected_branches

  • start_mirroring: project_id*

Remote mirrors (mirror_*):

  • mirror_list: project_id*

  • mirror_get / mirror_delete: project_id*, mirror_id*

  • mirror_get_public_key: project_id*, mirror_id*

  • mirror_add: project_id*, url*, enabled, keep_divergent_refs, only_protected_branches, mirror_branch_regex, auth_method (password/ssh_public_key)

  • mirror_edit: project_id*, mirror_id*, enabled, keep_divergent_refs, only_protected_branches, mirror_branch_regex, auth_method

  • mirror_force_push: project_id*, mirror_id*

Maintenance:

  • start_housekeeping / repository_storage_get / statistics_get: project_id*

Admin:

  • create_for_user: user_id*, name*, path, namespace_id, description, visibility, initialize_with_readme, default_branch, topics

See also: gitlab_repository (files/commits), gitlab_branch, gitlab_wiki, gitlab_issue, gitlab_merge_request, gitlab_discover_project (find project ID)

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?

Annotations already set destructiveHint=true and openWorldHint=true. The description adds extensive behavioral context: idempotency of actions (reads vs mutations), side effects (webhook deliveries, user notifications), and destructive actions. It also details return types and error hints, going well beyond annotations.

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?

The description is long but well-structured with clear sections (Behavior, Returns, Errors, Param conventions, then action groups). Every section earns its place given the tool's complexity. Minor deduction for length; could be slightly more concise but is appropriately detailed.

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?

Given the tool's massive scope (100+ actions), annotations (destructiveHint, openWorldHint), input schema (action+params), and presence of an output schema, the description covers all necessary aspects: action categories, parameter details, return types, errors, conventions, and sibling differentiation. Nothing essential is missing.

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?

The input schema has 100% coverage via descriptions of 'action' and 'params'. The description adds immense value by listing per-action parameters, conventions (e.g., project_id*, access levels), common params like page/per_page, and even enum values for visibility and merge methods. This far exceeds the schema alone.

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?

The description clearly states the tool's purpose: 'Manage GitLab projects end-to-end' and explicitly lists the scope. It differentiates from siblings by stating what NOT to use it for (e.g., 'NOT for: file content/commits (use gitlab_repository)...'). This provides a specific verb+resource and distinguishes it from sibling tools.

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?

The description provides explicit when-to-use ('project-level configuration and metadata') and when-not-to-use guidelines with specific sibling tool names. It also gives hints like 'Most mutations require Maintainer+; settings/transfers require Owner', helping the agent decide appropriateness.

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