Skip to main content
Glama

Delete wiki page

gitlab_delete_wiki_page
DestructiveIdempotent

Deletes a wiki page from a GitLab project by project ID and page slug, removing outdated or unwanted documentation via the GitLab API.

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.

Input Schema

NameRequiredDescriptionDefault
dataNo
fileNo
slugNo
titleNo
branchNo
contentNo
versionNo
project_idNo
format_typeNo
render_htmlNo
with_contentNo
api_parametersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv27.3.13

TDQS

C2.9/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the danger profile is covered structurally. The description adds two genuinely new facts: a successful deletion returns no data, and missing project_id/slug raises MissingParameterError. It says nothing about irreversibility, confirmation, or what 'slug' identifies.

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 purpose is front-loaded in the first sentence, which is good, but the body is auto-generated docstring boilerplate ('**kwargs: Additional parameters for the request') that is vague and consumes space. It is short enough overall, but roughly half the text is low-value scaffolding.

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 destructive operation, the description does cover the return behavior and the missing-parameter failure, and there is no output schema to explain. However, with 12 parameters at 0% coverage and nothing said about irreversibility or identifying the target page, it falls short of what a delete tool needs.

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% and there are 12 parameters, so the description must compensate and largely does not. It names only project_id and slug (as examples under '**kwargs'), leaving title, content, branch, file, data, version, format_type, render_html, with_content, and api_parameters entirely unexplained. A caller cannot tell which of the other ten are ignored by a delete.

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 sentence gives a specific verb and resource: 'Delete a wiki page for a project.' That separates it cleanly from gitlab_create_wiki_page, gitlab_update_wiki_page, and gitlab_get_wiki_page in the sibling list. It does not explicitly name or contrast with those siblings, so it stops just 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 explicit statement of when to use this tool rather than gitlab_update_wiki_page or gitlab_get_wiki_page, and no stated prerequisites such as required permissions. The only usable usage signal is indirect: the Raises section implies project_id and slug must be supplied. That is inference, not guidance.

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