Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_issue

Create a new GitLab issue for a project by providing a title and optional description, labels, assignees, milestone, weight, or issue type.

Instructions

Create a new issue. Open a new issue. Use update_issue for an existing issue and create_issue_note for discussion.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "title": "<title>"
    },
    "name": "create_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesIssue title
labelsNoLabel names
weightNoIssue weight
jmespathNoOptional JMESPath expression filtering the JSON result before return.
issue_typeNoissue, incident, test_case, or taskissue
project_idYesProject ID or complete URL-encoded path to project
descriptionNoIssue description
assignee_idsNoAssignee user IDs
milestone_idNoMilestone ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.3.22
    • changedInput schema / properties / assignee_ids / description
      Previous value: -"Array of user IDs to assign"New value: +"Assignee user IDs"
    • changedInput schema / properties / issue_type / description
      Previous value: -"The type of issue. One of issue, incident, test_case or task."New value: +"issue, incident, test_case, or task"
    • changedInput schema / properties / labels / description
      Previous value: -"Array of label names"New value: +"Label names"
    • changedInput schema / properties / milestone_id / description
      Previous value: -"Milestone ID to assign"New value: +"Milestone ID"
    • changedInput schema / properties / weight / description
      Previous value: -"Weight of the issue (numeric, typically hours of work)"New value: +"Issue weight"
  2. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  3. Changed1 schema field changedv2.1.62
    • changedInput schema / required
      Previous value: -[
-  "title",
-  "project_id"
-]New value: +[
+  "project_id",
+  "title"
+]
  4. Addedv2.1.18
  5. Removedv2.1.14
  6. Addedv2.1.11
  7. Removedv2.1.10
  8. Changed7 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / issue_type / anyOf
      Removed value: -[
-  {
-    "description": "the type of issue. One of issue, incident, test_case or task.",
-    "enum": [
-      "issue",
-      "incident",
-      "test_case",
-      "task"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • changedInput schema / properties / issue_type / description
      Previous value: -"the type of issue. One of issue, incident, test_case or task."New value: +"The type of issue. One of issue, incident, test_case or task."
    • addedInput schema / properties / issue_type / enum
      Added value: +[
+  "issue",
+  "incident",
+  "test_case",
+  "task"
+]
    • addedInput schema / properties / issue_type / type
      Added value: +"string"
    • addedInput schema / properties / weight
      Added value: +{
+  "description": "Weight of the issue (numeric, typically hours of work)",
+  "type": "number"
+}
    • changedInput schema / required
      Previous value: -[
-  "title"
-]New value: +[
+  "title",
+  "project_id"
+]
  9. First observedv1.0.0

TDQS

B3.2/5.0
Behavior2/5

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

The only annotation is openWorldHint=true, so the description carries the burden for a mutation tool. It says nothing about required permissions, whether creation triggers notifications or side effects, what happens on duplicate titles, or what the call returns. Beyond the word 'Create,' no behavior is disclosed.

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

Conciseness3/5

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

Two sentences are useful and one is pure redundancy ('Open a new issue'). The tool-routing sentence is valuable but should lead or merge with the purpose statement to be properly front-loaded.

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

Completeness2/5

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

Nine parameters, no output schema, and a write operation in an open world – the description gives no information about permission requirements, return payload, or side effects. An agent can call this but cannot predict the consequences or interpret the response from the definition alone.

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%, including enum values for issue_type and guidance on project_id, so the schema does the heavy lifting. The description adds no meaning about parameters, not even the two required ones or the optional result-filtering jmespath. Baseline 3 applies.

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 first sentence states a specific verb+resource ('Create a new issue'). The second sentence, 'Open a new issue,' is a near-verbatim restatement and adds nothing. Sibling differentiation is handled in the third sentence rather than the purpose line itself, so the intent is clear but not tightly front-loaded.

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?

Explicitly routes the agent: use `update_issue` for existing issues and `create_issue_note` for discussion. That covers the most likely mis-selection among siblings. It stops short of stating preconditions (e.g. project must exist, membership required) or when not to create at all.

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

Deploy Server

Other Tools