gitlab-api

Create group deploy token

gitlab_create_group_deploy_token

Create a deploy token for a GitLab group and retrieve its secret once at creation; store it immediately, as later reads do not return the token.

Instructions

Create a deploy token for a group.

Returns a secret: the new token string is returned once, at creation, and never by any read call. Store it now.

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

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

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

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_group_deploy_token"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`page`	No
`token`	No
`scopes`	No
`group_id`	No
`per_page`	No
`username`	No
`max_pages`	No
`expires_at`	No
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

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

changedInput schema / properties / page / default
```
Previous value: -1New value: +null
```
changedInput schema / properties / per_page / default
```
Previous value: -100New value: +null
```

First observedv27.3.13Oct 25, 2026

TDQS

B3.1/5.0

Behavior4/5

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

The annotations cover the mutation profile (readOnly=false, idempotent=false, non-destructive), so the bar is lower, yet the description still adds critical behavior: the token secret is returned exactly once and never by any read call, so it must be stored immediately. It also names the exception types raised. Not a 5 because nothing is said about scope defaults, expiration, or rate/privilege constraints.

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 secret-is-returned-once warning is front-loaded and is the highest-value sentence. The rest is generic docstring scaffolding — a kwargs catch-all and a boilerplate Raises list — that adds length without adding information.

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

Completeness3/5

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

For a mutation tool with no output schema, the description covers the two things an agent most needs: it is a create, and the secret is non-retrievable. However, with 10 entirely undocumented parameters and zero required fields, the definition does not tell the agent what a valid call looks like, which is a real gap.

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 coverage is 0% across 10 parameters, so the description must carry the load, but it only says "**kwargs: Additional parameters for the request (e.g., group_id, name, scopes)". Three of ten parameters are hinted at with no types, no required/optional marking, and no explanation of expires_at, project_id, token, username, or pagination fields.

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?

"Create a deploy token for a group" gives a specific verb and resource, and the group scope implicitly separates it from the project-level sibling. It stops short of naming alternatives or clarifying what a deploy token grants, so it is clear but not fully differentiating.

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 guidance on when to use this instead of gitlab_create_project_deploy_token, no prerequisite such as required group role, and no note that this is a one-shot creation that cannot be recovered. The agent gets no routing or precondition information.

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

Deploy Server