gitlab-api

Create wiki page

gitlab_create_wiki_page

Create a new wiki page in a GitLab project by supplying the project ID and page details such as title, content, slug, or branch.

Instructions

Create a new wiki page for a project.

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

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

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

Input Schema

Name	Required	Description	Default
`data`	No
`file`	No
`slug`	No
`title`	No
`branch`	No
`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
-}

First observedv27.3.13Oct 25, 2026

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, and the description adds only error class names and a return-wrapper note. Worse, it describes the call as taking '**kwargs: Additional parameters for the request (e.g., project_id)', which misrepresents a fixed 11-parameter schema and gives the agent a false model of the call surface. No mention of what happens on a duplicate slug/title or of overwrite behavior.

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?

It is short and front-loads the purpose in the first sentence, but the remainder is autogenerated docstring boilerplate ('Args/Returns/Raises') that spends lines on wrapper internals while omitting the fields that actually matter. Nothing is bloated, but much of the text does not earn its place.

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?

This is a mutating, open-world tool with 11 undocumented parameters and no output schema, so the description needed to explain the payload fields and the failure modes for duplicates. It covers only the error types and the response wrapper, leaving the agent unable to construct a valid call from the description plus schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/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 carries the full burden and fails: title, content, slug, branch, file, version, format_type, render_html, with_content and data are never mentioned. The only parameter reference is the '**kwargs (e.g., project_id)' boilerplate, which is actively misleading rather than informative.

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 ('Create a new wiki page for a project'), which is unambiguous on its own. It does not, however, distinguish this from the sibling gitlab_update_wiki_page or explain the create-vs-update boundary, so it stops 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 when-to-use guidance: nothing says to call update_wiki_page when the page already exists, nothing about required permissions or role, and nothing about which project scope applies. The agent must infer all routing from the tool name alone.

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

Deploy Server