Skip to main content
Glama

Delete tag

gitlab_delete_tag
DestructiveIdempotent

Deletes a GitLab project tag by project ID and tag name, removing the specified tag reference from the repository. Use it to clean up obsolete or incorrectly created tags.

Instructions

Delete a tag in a project.

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

Returns: Response: A wrapper containing the original response (no data for successful deletion).

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

Input Schema

NameRequiredDescriptionDefault
refNo
tagNo
pageNo
messageNo
per_pageNo
max_pagesNo
project_idNo
api_parametersNo

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=true, idempotent=true and openWorld=true, so the safety profile is covered. The description adds value by noting the successful response contains no data and by listing MissingParameterError/ParameterError conditions, but it omits whether protected tags block deletion or what permissions are required.

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 docstring is front-loaded with purpose and reasonably short, but the Args/Returns/Raises boilerplate devotes space to kwargs while omitting real parameter detail, and the 'name' reference is wasted/misleading text.

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?

A destructive, 8-parameter tool with no output schema and zero schema description coverage gets an inadequate description: parameter names are wrong, pagination params are unexplained, and protected-tag/permission behavior is not addressed.

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 8 parameters, so the description must compensate and does not. Worse, it names 'project_id, name' while the schema's parameter is 'tag', which is actively misleading; pagination-style params (page, per_page, max_pages) on a delete operation are left unexplained.

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?

States a specific verb and resource ('Delete a tag in a project'), which is clearly distinguishable from siblings like gitlab_create_tag, gitlab_get_tag, and gitlab_delete_branch. It does not explicitly reference those siblings, but the purpose is unambiguous.

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?

No indication of when to use this versus alternatives (e.g., gitlab_unprotect_tag, or checking gitlab_get_protected_tag first). No preconditions such as required permissions or protected-tag status are stated.

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