gitlab-api

Delete wiki page

gitlab_delete_wiki_page

DestructiveIdempotent

Deletes a GitLab project wiki page by project ID and slug, removing obsolete or unwanted documentation. Use it to clean up wiki content when a page is no longer needed.

Instructions

Delete a wiki page for a project.

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

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

Raises: MissingParameterError: If the project_id or slug 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_wiki_page"
  }
}

Input Schema

Name	Required	Description
`data`	No
`file`	No
`slug`	No
`title`	No
`branch`	No
`confirm`	No	Explicitly confirm this destructive operation. Needed only when the client cannot answer a confirmation prompt.
`content`	No
`version`	No
`project_id`	No
`format_type`	No
`render_html`	No
`with_content`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "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 readOnlyHint=false, so the risk profile is covered structurally. The description adds genuine context by stating the return is a wrapper with no data on successful deletion and listing the MissingParameterError/ParameterError conditions. It omits the most important behavioral detail for a destructive tool: that the `confirm` flag exists for clients that cannot answer a confirmation prompt.

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 opening sentence is front-loaded and clear, and the overall length is short. However, the "Args: **kwargs: Additional parameters for the request" block is boilerplate that conveys no real information and could be replaced with the actual identifying parameters.

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, open-world tool with 12 mostly undocumented parameters and no output schema, the description is thin. It never explains how the page is identified (slug vs. title), what confirm does, or that deletion is irreversible, all of which an agent needs before invoking it.

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 only 8% across 12 parameters, so the description must carry the burden and largely fails. It identifies project_id and slug as required, but lumps everything else under "**kwargs: Additional parameters," leaving title, branch, content, version, format_type, render_html, with_content, data, file, and confirm entirely 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?

The description names a specific verb and resource ("Delete a wiki page for a project"), so an agent knows exactly what the tool does. It does not distinguish itself from the closely related siblings gitlab_get_wiki_page, gitlab_update_wiki_page, or gitlab_create_wiki_page, so it falls short of a 5.

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 deletion tool versus updating or reading a wiki page, and no mention of prerequisites such as permissions or the confirmation flow. The only implicit usage signal is the note that project_id or slug must be present, which comes from the error section rather than deliberate guidance.

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

Deploy Server