gitlab-api

Edit group level rule

gitlab_edit_group_level_rule

Idempotent

Edit GitLab group-level merge request approval settings to control approval permissions, reauthentication, and code owner removal rules.

Instructions

Edit a group-level merge request approval setting.

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

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

Raises: MissingParameterError: If the group_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_edit_group_level_rule"
  }
}

Input Schema

Name	Required	Description	Default
`data`	No
`group_id`	No
`project_id`	No
`allow_author_approval`	No
`allow_committer_approval`	No
`retain_approvals_on_push`	No
`selective_code_owner_removals`	No
`require_reauthentication_to_approve`	No
`allow_overrides_to_approver_list_per_merge_request`	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.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation profile is covered. The description adds only boilerplate error names (MissingParameterError, ParameterError) and a return-wrapper note, without explaining what an edit does to unset fields, whether omitted booleans are left unchanged, or whether changes apply to existing projects in the group.

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 core sentence is front-loaded and clear, but the rest is autogenerated docstring scaffolding. The '**kwargs: Additional parameters' line is misleading given the schema exposes named, typed properties, and the Args/Returns/Raises blocks add bulk without adding meaning.

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 9-parameter mutation with no output schema, the description should identify which settings are editable and how unset values are treated. It only confirms the return wrapper contains a MergeRequestRuleSettings model, leaving the agent unable to choose correct parameter values from the description and schema alone.

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?

With 9 parameters at 0% schema description coverage, the description must compensate, and it largely does not: the eight boolean approval settings (allow_author_approval, retain_approvals_on_push, etc.) are never mentioned or explained. It adds one useful fact — that group_id is effectively required via MissingParameterError — which actually conflicts with the schema reporting zero required parameters.

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 names a specific verb and resource ('Edit a group-level merge request approval setting'), and the 'group-level' scoping implicitly separates it from the sibling gitlab_edit_project_level_rule. It stops short of naming that sibling explicitly, so differentiation still requires the agent to read the tool name.

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 instead of gitlab_edit_project_level_rule, gitlab_create_project_level_rule, or gitlab_get_group_level_rule. Nothing tells the agent to inspect the existing rule first, or what permissions/role are needed to change group approval settings.

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

Deploy Server