gitlab mcp

update_project

Update existing GitLab project settings such as visibility, default branch, and feature access levels. Modifies remote state, requiring the correct project permissions.

Instructions

Update project settings such as description, visibility, default branch, and feature access levels. Use this for an existing resource; choose the corresponding create tool for a new resource and a note tool for discussion-only text. It changes remote GitLab state and requires the necessary project or group permission; GitLab returns validation, conflict, permission, or rate-limit errors instead of silently applying an invalid request. When project_id or group_id is accepted, provide the numeric ID or complete URL-encoded path described by the schema; use required identifiers and pagination fields exactly as documented.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Project display name
`path`	No	Project path/slug
`topics`	No	Project topics
`jmespath`	No	Optional JMESPath expression filtering the JSON result before return.
`project_id`	Yes	Project ID or complete URL-encoded path to project
`visibility`	No	Project visibility
`description`	No	Project description
`merge_method`	No	Merge method
`squash_option`	No	Squash commits setting
`default_branch`	No	Default branch name
`wiki_access_level`	No	Wiki feature visibility
`pages_access_level`	No	Pages feature visibility
`builds_access_level`	No	CI/CD pipelines feature visibility
`issues_access_level`	No	Issues feature visibility
`forking_access_level`	No	Forking feature visibility
`snippets_access_level`	No	Snippets feature visibility
`request_access_enabled`	No	Allow users to request access
`environments_access_level`	No	Environments feature visibility
`merge_requests_access_level`	No	Merge requests feature visibility
`package_registry_access_level`	No	Package registry feature visibility
`container_registry_access_level`	No	Container registry feature visibility
`remove_source_branch_after_merge`	No	Remove source branches after merge by default
`only_allow_merge_if_pipeline_succeeds`	No	Require successful pipeline before merge
`only_allow_merge_if_all_discussions_are_resolved`	No	Require all discussions to be resolved before merge

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.1.66Sep 23, 2026

addedInput schema / properties / jmespath

Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}

Changed1 schema field changedv2.1.62Sep 16, 2026
- addedInput schema / required
```
Added value: +[
+  "project_id"
+]
```
Addedv2.1.26Jun 21, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description clearly states that it changes remote GitLab state, requires appropriate project or group permissions, and that GitLab returns validation, conflict, permission, or rate-limit errors rather than silently applying invalid requests. This is valuable context beyond the openWorldHint annotation and directly informs the agent of side effects and error handling 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?

The description is front-loaded with purpose and usage, but it contains extraneous and potentially confusing details (group_id and pagination fields that do not exist in the schema). It is not as concise or accurate as it could be; each sentence should earn its place, and the last sentence slightly derails the focus.

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 tool with 24 parameters and no output schema, the description covers purpose, usage, and error behavior, but it incorrectly references group_id and pagination fields, which are not part of the input schema. This inaccuracy could mislead an agent about the tool's actual scope. It also does not clarify that only project_id is required, though that is visible in the schema. Overall it is mostly complete but has notable gaps and a distracting error.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter semantics beyond the schema; it repeats that project_id can be a numeric ID or URL-encoded path (already documented in schema) and oddly references group_id and pagination fields, which are not present in the schema. This does not genuinely enhance understanding of the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Update') and resource ('project'), then lists concrete examples of settings (description, visibility, default branch, feature access levels). It also distinguishes itself from create and note tools for new resources and discussion-only text, so an agent can tell it apart from its primary siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it for an existing resource and to choose the corresponding create tool for a new resource and a note tool for discussion-only text. However, it does not mention the more directly overlapping sibling 'update_default_branch' as a specialized alternative for changing just the default branch, leaving that differentiation to inference.

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

Deploy Server

update_project

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools