gitlab-api

Delete runner

gitlab_delete_runner

DestructiveIdempotent

Delete a GitLab runner by specifying its runner_id to clean up unused or compromised CI/CD runners.

Instructions

Delete a runner.

Args: **kwargs: Additional parameters for the request (e.g., runner_id, token).

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

Raises: MissingParameterError: If the runner_id or token 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_delete_runner"
  }
}

Input Schema

Name	Required	Description
`data`	No
`info`	No
`token`	No
`active`	No
`locked`	No
`paused`	No
`status`	No
`confirm`	No	Explicitly confirm this destructive operation. Needed only when the client cannot answer a confirmation prompt.
`group_id`	No
`tag_list`	No
`max_pages`	No
`runner_id`	No
`project_id`	No
`all_runners`	No
`description`	No
`runner_type`	No
`access_level`	No
`run_untagged`	No
`maximum_timeout`	No
`maintenance_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv27.3.20Nov 7, 2026

changedInput schema / properties / all_runners / default
```
Previous value: -falseNew value: +null
```

removedInput schema / properties / api_parameters

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

addedInput schema / properties / max_pages

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed1 schema field changedv27.3.18Nov 6, 2026

addedInput schema / properties / confirm

Added value: +{
+  "default": false,
+  "description": "Explicitly confirm this destructive operation. Needed only when the client cannot answer a confirmation prompt.",
+  "type": "boolean"
+}

First observedv27.3.13Oct 25, 2026

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 usefully adds that successful deletion returns no data and that MissingParameterError is raised when runner_id or token is absent, but it never mentions the confirm flag or that runner_id is expected despite the schema marking nothing 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 text is short and the purpose line is front-loaded, but it is a raw docstring with an Args/Returns/Raises skeleton where the Args section is a misleading "**kwargs" catch-all rather than real parameter documentation.

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, 20-parameter, no-output-schema tool, the description omits the confirmation flow, which identifier (runner_id versus project_id/group_id) actually selects the runner, and how this differs from the project-runner delete sibling. Only the empty-return and error behavior are covered.

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?

The schema has 20 parameters at 5% description coverage, and the description only names runner_id and token while calling everything else "**kwargs". The other 18 parameters, including confirm, project_id, group_id and runner_type, get no explanation of their role in a delete call.

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 states a specific verb and resource: "Delete a runner." That is unambiguous on its own, but it gives no signal for distinguishing an instance-level runner deletion from the sibling gitlab_delete_project_runner, which an agent must pick between.

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 exclusion of alternatives, and no note about when a project-scoped runner deletion is preferable. The only selection hint is the generic list of siblings.

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

Deploy Server