gitlab-api

Create release

gitlab_create_release

Create a GitLab project release by specifying the project ID and tag name, with optional release details such as name, description, milestones, and assets.

Instructions

Create a new release in a project.

Args: **kwargs: Additional parameters for the request (e.g., project_id, tag_name).

Returns: Response: A wrapper containing the original response and a Release model.

Raises: MissingParameterError: If the project_id or tag_name is missing. ParameterError: If invalid parameters are provided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gitlab_create_release"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	No
`data`	No
`name`	No
`page`	No
`sort`	No
`simple`	No
`group_id`	No
`order_by`	No
`per_page`	No
`tag_name`	No
`max_pages`	No
`milestones`	No
`project_id`	No
`description`	No
`released_at`	No
`tag_message`	No
`total_pages`	No
`direct_asset_path`	No
`include_html_description`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

First observedv27.3.13Oct 25, 2026

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds real value by naming the error types (MissingParameterError for project_id/tag_name, ParameterError for bad parameters) and describing the wrapped Release return, but it omits the important side effect of whether a release creates an underlying tag and what happens on duplicate tag_name.

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?

The purpose line is front-loaded, which is good, but the remainder is a generic docstring template and the '**kwargs' line is actively misleading given the schema's explicit, non-kwargs properties. Nothing here is verbose, but a portion of the text does not earn its place.

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?

For a 19-parameter, non-idempotent write operation with zero schema description coverage and no output schema, the description is far too thin. An agent has no way to know which of the 17 undocumented optional fields it should populate to create a usable release, or what the tag-related preconditions are.

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

Parameters2/5

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

Schema description coverage is 0% across 19 parameters, so the description carries the full explanatory burden and does not meet it. It only names project_id and tag_name — and does so inaccurately as '**kwargs: Additional parameters' — while ref, name, description, released_at, tag_message, milestones, direct_asset_path, and include_html_description go entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a clear verb and resource ('Create a new release in a project'), but it is identical in spirit to the title 'Create release' and does nothing to separate it from nearby siblings such as gitlab_create_release_evidence, gitlab_update_release, or gitlab_delete_release. The subsequent Args/Returns/Raises boilerplate dilutes rather than sharpens the purpose.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisite conditions (e.g., whether the tag must already exist or whether this creates a tag), and no mention of alternatives like create_release_evidence or update_release. The agent must infer everything about selection from the tool name alone.

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

Deploy Server