Skip to main content
Glama

Delete project deploy token

gitlab_delete_project_deploy_token
DestructiveIdempotent

Delete a GitLab project deploy token by specifying project and token IDs to revoke access for a compromised or obsolete deployment credential.

Instructions

Delete a deploy token for a project.

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

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

Raises: ParameterError: If invalid parameters are provided. MissingParameterError: If required parameters are missing.

Input Schema

NameRequiredDescriptionDefault
nameNo
pageNo
tokenNo
scopesNo
group_idNo
per_pageNo
usernameNo
max_pagesNo
expires_atNo
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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds a useful fact beyond that — successful deletion returns no data — plus the ParameterError/MissingParameterError behaviors. It omits permission requirements and irreversibility consequences, so it is additive but not rich.

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 operational sentence is front-loaded and clear, but the Args/Returns/Raises block is largely boilerplate docstring scaffolding, and the Args entry spends a line on a parameter that does not exist. Reasonable size, mixed value per sentence.

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, 11-parameter operation with no output schema, the description leaves the most consequential question unanswered: which field identifies the target token. It also says nothing about permissions or side effects beyond the empty response, leaving the agent under-equipped to call it correctly.

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 11 parameters, so the description must compensate and does not. Worse, it cites `deploy_token_id` as an example argument while no such property exists in the schema, which actively misleads the agent about how to identify the token to delete (possible candidates: name, token, project_id).

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 line gives a specific verb and resource ("Delete a deploy token for a project"), which cleanly separates it from create/get siblings and from gitlab_delete_group_deploy_token by scope. It stops short of naming the sibling it contrasts with, but an agent can identify the operation immediately.

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 such as gitlab_delete_group_deploy_token, nor any prerequisites (required permissions, whether the token must be revoked first). Usage is only inferable from the tool name.

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