Skip to main content
Glama

Delete release

gitlab_delete_release
DestructiveIdempotent

Delete a GitLab project release by project_id and tag_name to remove the release and its metadata when no longer needed.

Instructions

Delete a 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 (no data for successful deletion).

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

Input Schema

NameRequiredDescriptionDefault
refNo
dataNo
nameNo
pageNo
sortNo
simpleNo
group_idNo
order_byNo
per_pageNo
tag_nameNo
max_pagesNo
milestonesNo
project_idNo
descriptionNo
released_atNo
tag_messageNo
total_pagesNo
api_parametersNo
direct_asset_pathNo
include_html_descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv27.3.13

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare destructive, idempotent, non-read-only, open-world behavior. The description adds real value beyond them by stating that a successful deletion returns a wrapper with no data and that MissingParameterError/ParameterError are raised, which clarifies the specific failure modes. It does not discuss permissions, side effects (e.g. associated assets/tags), or irreversibility beyond the annotation hint.

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 text is short and the purpose line is front-loaded, but the Args/Returns/Raises docstring boilerplate is partially wasted (generic **kwargs restatement) and the useful fact that project_id and tag_name are required is buried inside an exception note rather than stated up front.

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 destructive tool with 20 undocumented parameters and no output schema, the description should at minimum tell the agent which parameters are meaningful and what side effects occur. It covers the return and error surface, but leaves the parameter surface almost entirely opaque, which is the biggest risk for this call.

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 20 parameters, so the description must carry the burden and it does not. It only identifies project_id and tag_name as required (via the MissingParameterError note) and lumps everything else into an opaque **kwargs; the other 18 parameters — many apparently copied from release creation such as description, milestones, released_at — are left unexplained with no hint that they are irrelevant to deletion.

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 description opens with a specific verb and resource ("Delete a release in a project"), which an agent can distinguish from the numerous non-release siblings. It does not, however, distinguish deletion of a release from related destructive siblings like gitlab_delete_tag, which is a plausible confusion.

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 statement of when to use this versus alternatives, nor any preconditions or cautions beyond error types. An agent gets no guidance on how this differs from gitlab_update_release or gitlab_delete_tag, which matter a great deal for a destructive operation.

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