Skip to main content
Glama

Issue

gitlab_issue
Destructive

Manage the full lifecycle of GitLab issues: create, update, close, move, comment, link, track time, add notes and discussions, award emoji, and handle work items, statistics, and resource events.

Instructions

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

Manage GitLab issues: CRUD, notes, discussions, links, time tracking, work items, award emoji, statistics, and resource events. When to use: issue lifecycle — create, update, close, move, comment, link, time-track, and manage Work Items (including Epics). NOT for: merge requests (use gitlab_merge_request), project settings (use gitlab_project), CI/CD (use gitlab_pipeline).

Side effects: delete/move are irreversible; move changes URL and IID. Time tracking uses dedicated actions — do NOT pass time params to update.

Returns: resource object for single-item actions; paginated list ({page, per_page, total, next_page}) for list / list / list_all / list_group / participants / mrs / iteration_list_*; GraphQL cursor pagination ({nodes, page_info}) for work_item_list; {success, message} for delete actions. Errors: 404 (hint: issue_iid is project-scoped — supply project_id; for list_all use scope/iids), 403 (hint: Reporter+ to comment, Developer+ to edit/move), 400 (hint: state_event ∈ close/reopen; dates ISO 8601; weight integer 0–9 — Premium+).

Param conventions: * = required. Most actions need project_id* + issue_iid*. List actions accept page, per_page. Work item actions use full_path* + work_item_iid* (GraphQL).

Issue CRUD:

  • create: project_id*, title*, description, assignee_id, assignee_ids ([]int), labels (comma-separated), milestone_id, due_date (YYYY-MM-DD), confidential, issue_type (issue/incident/test_case/task), weight, epic_id

  • get: project_id*, issue_iid*

  • get_by_id: issue_id* (global ID, no project_id needed)

  • list: project_id*, state (opened/closed/all), labels, not_labels, milestone, scope (created_by_me/assigned_to_me/all), search, assignee_username, author_username, iids ([]int), issue_type, confidential, created_after/before, updated_after/before (ISO 8601), order_by (created_at/updated_at/priority/due_date), sort (asc/desc)

  • list_all: global issue list (no project_id). Same filters as list.

  • list_group: group_id*, state, labels, milestone, scope, search, order_by, sort

  • update: project_id*, issue_iid*, title, description, state_event (close/reopen), assignee_id, assignee_ids, labels, add_labels, remove_labels, milestone_id, due_date, confidential, issue_type, weight, epic_id, discussion_locked

  • delete: project_id*, issue_iid* (permanent, irreversible)

  • reorder: project_id*, issue_iid*, move_after_id, move_before_id

  • move: project_id*, issue_iid*, to_project_id* (moves to another project)

  • subscribe / unsubscribe: project_id*, issue_iid*

  • create_todo: project_id*, issue_iid*

Time tracking:

  • time_estimate_set: project_id*, issue_iid*, duration* (e.g. 3h30m)

  • time_estimate_reset / spent_time_reset: project_id*, issue_iid*

  • spent_time_add: project_id*, issue_iid*, duration*, summary

  • time_stats_get: project_id*, issue_iid*

Participants & related MRs:

  • participants: project_id*, issue_iid*

  • mrs_closing / mrs_related: project_id*, issue_iid*

Notes (note_): project_id, issue_iid* for all.

  • note_list: order_by, sort

  • note_get / note_delete: note_id*

  • note_create: body*, internal

  • note_update: note_id*, body*

Issue links (link_): project_id, issue_iid* for all.

  • link_list

  • link_get / link_delete: issue_link_id*

  • link_create: target_project_id*, target_issue_iid*, link_type

Discussions (discussion_): project_id, issue_iid* for all.

  • discussion_list

  • discussion_get: discussion_id*

  • discussion_create: body*

  • discussion_add_note: discussion_id*, body*

  • discussion_update_note: discussion_id*, note_id*, body*

  • discussion_delete_note: discussion_id*, note_id*

Work Items (work_item_): full_path for all. Use types=["Epic"] to list epics (replaces deprecated epic_list).

  • work_item_list: state, search, types, author_username, label_name, confidential, sort, first, after

  • work_item_get: work_item_iid*

  • work_item_create: work_item_type_id*, title*, description, confidential, assignee_ids, milestone_id, label_ids, weight, health_status, color, due_date, start_date, linked_items {work_item_ids, link_type}

  • work_item_update: work_item_iid*, title, state_event (CLOSE/REOPEN), description, assignee_ids, milestone_id, crm_contact_ids, parent_id, add_label_ids, remove_label_ids, start_date, due_date, weight, health_status, iteration_id, color, status (TODO/IN_PROGRESS/DONE/WONT_DO/DUPLICATE)

  • work_item_delete: work_item_iid* (permanent)

Statistics:

  • statistics_get: global issue stats (optional filters same as list)

  • statistics_get_group: group_id*

  • statistics_get_project: project_id*

Award emoji (emoji_issue_): project_id, issue_iid* for all.

  • emoji_issue_list / emoji_issue_get (+ award_id*) / emoji_issue_delete (+ award_id*)

  • emoji_issue_create: name*

  • emoji_issue_note_list / emoji_issue_note_get: note_id*, (+ award_id* for get)

  • emoji_issue_note_create: note_id*, name*

  • emoji_issue_note_delete: note_id*, award_id*

Resource events (event_issue_): project_id, issue_iid* for all.

  • event_issue_label_list / event_issue_label_get (+ label_event_id*)

  • event_issue_milestone_list / event_issue_milestone_get (+ milestone_event_id*)

  • event_issue_state_list / event_issue_state_get (+ state_event_id*)

  • event_issue_iteration_list / event_issue_iteration_get (+ iteration_event_id*)

  • event_issue_weight_list

See also: gitlab_merge_request (MR lifecycle), gitlab_project (project settings, labels, milestones), gitlab_pipeline (CI/CD).

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 annotations already declare destructiveHint: true, but the description adds critical behavioral details: 'delete/move are irreversible; move changes URL and IID. Time tracking uses dedicated actions — do NOT pass time params to update.' It also explains error conditions (404, 403, 400) with hints. No contradiction 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?

The description is very long but well-structured with logical sections (Issue CRUD, Time tracking, Notes, etc.) and bolded action names. It front-loads general info. While not extremely concise, the length is justified by the tool's 59 actions. A slight improvement could be more whitespace or bullet lists.

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 (59 actions, nested params, multiple sub-resources), the description is remarkably complete. It covers all actions with parameter lists, side effects, error hints, return types, and even mentions pagination formats. It also refers to an external schema. 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 only two parameters (action, params), but the description adds immense semantic value by listing all 59 actions with their required and optional parameters, parameter conventions, and examples (e.g., 'create: project_id*, title*, description...'). It also references an external schema resource for validation. Schema coverage is 100% but the description complements it richly.

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 issues: CRUD, notes, discussions, links, time tracking, work items, award emoji, statistics, and resource events.' It explicitly distinguishes from sibling tools by stating 'NOT for: merge requests (use gitlab_merge_request), project settings (use gitlab_project), CI/CD (use gitlab_pipeline).' The verb 'Manage' plus the comprehensive list of actions leaves no ambiguity.

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 guidance: 'issue lifecycle — create, update, close, move, comment, link, time-track, and manage Work Items (including Epics).' It also specifies when NOT to use it and names alternative tools. Additionally, it references 'See also' section listing related tools. This is thorough and actionable.

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