Skip to main content
Glama
zereight

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

approve_merge_request

Record your approval on a merge request without merging it. Use this to update review state, verify the request is unchanged, and handle re-authentication when required.

Instructions

Approve a merge request. Use this to record an approval on an existing merge request; it does not merge the request or change its source branch. The operation changes review state, may require re-authentication or approval permission, and returns the updated approval result or a permission/state error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shaNoThe HEAD of the merge request. Optional, but used to ensure the merge request hasn't changed since you last reviewed it
jmespathNoOptional JMESPath expression filtering the JSON result before return.
project_idYesProject ID or complete URL-encoded path to project
approval_passwordNoCurrent user's password. Required if 'Require user re-authentication to approve' is enabled in the project settings
merge_request_iidYesThe IID of the merge request to approve

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  2. Addedv2.1.45
  3. Removedv2.1.43
  4. Addedv2.1.18
  5. Removedv2.1.14
  6. Addedv2.1.11
  7. Removedv2.1.10
  8. Addedv2.1.9

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only provide openWorldHint: true, so the description carries the burden of behavioral disclosure. It states that the operation changes review state, may require re-authentication or approval permission, and returns an updated approval result or an error. This adds meaningful context beyond the annotation and aligns with the openWorldHint without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. The first sentence states the core purpose and the key exclusion (does not merge), and the second covers side effects, authentication, and return type. Information is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and no output schema, the description adequately covers the return value ('updated approval result or a permission/state error') and the key side effect (review state change). It doesn't elaborate on parameter usage, but the schema covers that. The only minor gap is not mentioning the `sha` concurrency check, but that is documented in the schema.

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 coverage is 100%, so all five parameters are already documented in the input schema. The description does not add extra parameter-level detail, which is acceptable given the schema's thoroughness. Baseline 3 is appropriate because the schema handles the parameter explanations.

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 clearly states the verb (approve), the resource (merge request), and the exact scope: it records an approval and explicitly clarifies it does not merge or change the source branch. This distinguishes it from sibling tools like merge_merge_request and unapprove_merge_request.

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 says 'Use this to record an approval on an existing merge request' and contrasts with merging, so the agent knows when to call it. It also mentions potential re-authentication and permission requirements, giving practical usage context. It doesn't explicitly name alternatives like unapprove, but the core distinction from merge is sufficient.

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