Skip to main content
Glama

Group

gitlab_group
Destructive

Manage GitLab groups with group-level operations: CRUD, subgroups, members, labels, milestones, webhooks, badges, boards, uploads, and import/export.

Instructions

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

Manage GitLab groups: CRUD, subgroups, members, labels, milestones, webhooks, badges, boards, uploads, and import/export. When to use: group-level operations (groups, subgroups, members, labels, milestones, boards, webhooks, badges, wikis, epics). NOT for: project-specific operations (use gitlab_project or gitlab_merge_request), user accounts (use gitlab_user), cross-project search (use gitlab_search).

Behavior:

  • Idempotent reads: get / list / projects / members / subgroups / issues / search / _list / get / hook_list / badge_list / group_label_list / group_milestone_list / group_board_list / release_list (Premium+ adds wiki_list / epic_list / protectedlist / ldap_link_list / saml_link_list / service_account_list).

  • update / *_update / *_edit / archive / unarchive are idempotent (same input → same state). create / *_create / hook_add are NON-idempotent (re-invocation creates a duplicate or returns 409).

  • Side effects: group_member_add / group_member_share / group_member_edit may notify the invited user/group; hook_add / hook_edit trigger webhook deliveries; transfer_project moves repository data and re-permissions members; ldap/saml link mutations re-evaluate group membership on next sign-in (read-after-write may lag).

  • Destructive: delete cascades to subgroups, projects, members, issues, MRs (irreversible when permanently_remove=true; restore window applies otherwise); hook_delete, badge_delete, group_label_delete, group_milestone_delete, group_board_delete, group_upload_delete_* are irreversible. Premium+ adds destructive: epic_delete, wiki_delete, protected__unprotect, ldap_link_delete, saml_link_delete, service_account_delete, service_account_pat_revoke. archive is reversible via unarchive.

Returns: JSON with resource data. Lists include pagination (page, per_page, total, next_page). Void actions return confirmation. Errors: 404 (hint: group_id can be numeric ID or URL-encoded full path), 403 (hint: most mutations require Maintainer+; group_member_share, transfer_project and service_account_* require Owner), 400 (hint: visibility ∈ private/internal/public; permanently_remove=true requires full_path).

Param conventions: * = required. Most actions need group_id* (numeric ID or URL-encoded path like 'group/subgroup'). List actions accept page, per_page.

Group CRUD:

  • list: search, owned, top_level_only (no group_id needed)

  • get: group_id*

  • create: name*, path, description, visibility (private/internal/public), parent_id, request_access_enabled, lfs_enabled, default_branch

  • update: group_id*, name, path, description, visibility, request_access_enabled, lfs_enabled, default_branch

  • delete: group_id*, permanently_remove, full_path (required when permanently_remove=true)

  • restore: group_id*

  • archive / unarchive: group_id* (requires Owner role)

  • search: query* (no group_id needed)

  • transfer_project: group_id*, project_id*

Group queries:

  • projects: group_id*, search, include_subgroups (recommended for hierarchies), archived, visibility, order_by, sort, simple, owned, starred, with_shared

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

  • subgroups: group_id*, search

  • issues: group_id*, state, labels, milestone, scope, search, assignee_username, author_username

Webhooks (hook_*):

  • hook_list: group_id*

  • hook_get / hook_delete: group_id*, hook_id*

  • hook_add: group_id*, url*, name, description, token, event booleans (push/tag_push/merge_requests/issues/note/job/pipeline/wiki_page/deployment/releases/subgroup/member_events), enable_ssl_verification, push_events_branch_filter

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

Badges (badge_*):

  • badge_list: group_id*, name

  • badge_get / badge_delete: group_id*, badge_id*

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

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

Members (group_member_*):

  • group_member_get: group_id*, user_id*

  • group_member_get_inherited: group_id*, user_id* (includes inherited)

  • group_member_add / group_member_edit: group_id*, user_id*, access_level*, expires_at

  • group_member_remove: group_id*, user_id*

  • group_member_share: group_id*, shared_with_group_id*, group_access*, expires_at

  • group_member_unshare: group_id*, shared_with_group_id*

Labels (group_label_*):

  • group_label_list: group_id*, search, with_counts, include_ancestor_groups, include_descendant_groups

  • group_label_get / group_label_delete / group_label_subscribe / group_label_unsubscribe: group_id*, label_id*

  • group_label_create: group_id*, name*, color*, description

  • group_label_update: group_id*, label_id*, new_name, color, description

Milestones (group_milestone_*):

  • group_milestone_list: group_id*, state, title, search, include_ancestors, include_descendants

  • group_milestone_get / group_milestone_delete: group_id*, milestone_iid*

  • group_milestone_create: group_id*, title*, description, start_date, due_date

  • group_milestone_update: group_id*, milestone_iid*, title, description, start_date, due_date, state_event

  • group_milestone_issues / group_milestone_merge_requests / group_milestone_burndown: group_id*, milestone_iid*

Boards (group_board_*):

  • group_board_list: group_id*

  • group_board_get / group_board_delete: group_id*, board_id*

  • group_board_create: group_id*, name*

  • group_board_update: group_id*, board_id*, name, assignee_id, milestone_id, labels, weight

  • group_board_list_lists: group_id*, board_id*

  • group_board_get_list / group_board_delete_list: group_id*, board_id*, list_id*

  • group_board_create_list: group_id*, board_id*, label_id

  • group_board_update_list: group_id*, board_id*, list_id*, position

Uploads:

  • group_upload_list: group_id*

  • group_upload_delete_by_id: group_id*, upload_id*

  • group_upload_delete_by_secret: group_id*, secret*, filename*

Import/Export:

  • group_relations_schedule / group_relations_list_status: group_id*

  • group_export_schedule / group_export_download: group_id*

  • group_import_file: name*, path*, file*, parent_id (no group_id)

Releases:

  • release_list: group_id*, simple

See also: gitlab_project (project-level), gitlab_user (user management), gitlab_search (cross-project search), gitlab_merge_request (MR workflows)

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?

The description provides extensive behavioral details beyond the annotations (destructiveHint, openWorldHint). It covers idempotency (read operations, update/archive as idempotent; create/hook_add as non-idempotent), side effects (notifications, webhook triggers, data movement), destructive actions (cascading deletes, irreversibility conditions), error hints, and return formats. No contradictions with 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?

While the description is long, it is well-structured with clear sections (example, behavior, returns, errors, param conventions, action categories). Every sentence adds value given the tool's complexity. However, some redundancy exists (e.g., repeated param lists could be referenced once), slight reduction could improve conciseness.

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 complexity (50+ actions, many parameters), the description is remarkably complete. It covers all action categories, required parameters, behavior nuances, error handling, pagination, and output format. Since an output schema exists, the description does not need to detail return values, but it still mentions JSON with resource data and pagination.

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 only defines 'action' and 'params' generically, but the description lists all action-specific parameters in detail, marking required fields with '*'. For example, it specifies parameters for each CRUD, webhook, badge, member, label, milestone, board, upload, and import/export action. This completely compensates for the schema's lack of parameter-level detail.

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 explicitly states the tool's purpose: 'Manage GitLab groups: CRUD, subgroups, members, labels, milestones, webhooks, badges, boards, uploads, and import/export.' It also distinguishes from sibling tools by specifying that it is for group-level operations and not for project-specific, user, or search operations, with clear alternatives provided.

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 includes a dedicated 'When to use' section that explicitly states when to use this tool (group-level operations) and when not to, listing specific alternatives like 'gitlab_project', 'gitlab_user', and 'gitlab_search'. It also provides a 'See also' section with direct references to sibling tools.

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