Skip to main content
Glama
zereight

gitlab mcp

by zereight
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

push_files

Destructive

Commit multiple files atomically to a GitLab branch in a single commit. Supports create, update, delete, and move actions, with text or base64 encoding, returning the commit result or errors.

Instructions

Push multiple files in a single commit. Use this to commit several file changes atomically; use create_or_update_file when only one path is involved. Each file defaults to action create; optional per-file action (create/update/delete/move) and encoding (text/base64) are additive. GITLAB_PERMISSION_MODE=modify rejects delete and move. The operation writes repository history on the selected branch, requires repository write permission, and returns the commit result or a validation, conflict, or protected-branch error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesArray of files to push. Each entry defaults to action 'create'. Per-file fields: action (create/update/delete/move), encoding (text/base64; omitted uses GITLAB_REPO_FILE_ENCODING), previous_path (required for move). Content is required for create and update; omit content for delete, or for a move that should keep the original file. GITLAB_PERMISSION_MODE=modify rejects delete and move.
branchYesBranch to push to
project_idYesProject ID or complete URL-encoded path to project
commit_messageYesCommit message

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv2.1.52
    • changedInput schema / properties / files / description
      Previous value: -"Array of files to push"New value: +"Array of files to push. Each entry defaults to action 'create'. Per-file fields: action (create/update/delete/move), encoding (text/base64; omitted uses GITLAB_REPO_FILE_ENCODING), previous_path (required for move). Content is required for create and update; omit content for delete, or for a move that should keep the original file. GITLAB_PERMISSION_MODE=modify rejects delete and move."
    • addedInput schema / properties / files / items / properties / action
      Added value: +{
+  "description": "Commit action for this file. Defaults to 'create'.",
+  "enum": [
+    "create",
+    "update",
+    "delete",
+    "move"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / files / items / properties / content / description
      Previous value: -"Content of the file"New value: +"File content. Required for create and update. Omit for delete, or for a move that should keep the original content. Base64-encoded when encoding is 'base64'."
    • addedInput schema / properties / files / items / properties / encoding
      Added value: +{
+  "description": "Use 'base64' for binary files (content must already be base64-encoded). When omitted, GITLAB_REPO_FILE_ENCODING applies.",
+  "enum": [
+    "text",
+    "base64"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / files / items / properties / file_path / description
      Previous value: -"Path where to create the file"New value: +"Path of the file in the repo"
    • addedInput schema / properties / files / items / properties / previous_path
      Added value: +{
+  "description": "Previous path of the file. Required when action is 'move'.",
+  "type": "string"
+}
    • changedInput schema / properties / files / items / required
      Previous value: -[
-  "file_path",
-  "content"
-]New value: +[
+  "file_path"
+]
  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. Changed2 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / required
      Previous value: -[
-  "branch",
-  "files",
-  "commit_message"
-]New value: +[
+  "branch",
+  "files",
+  "commit_message",
+  "project_id"
+]
  9. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses that the tool writes repository history, requires repository write permission, and returns validation/conflict/protected-branch errors — behavior that complements the `destructiveHint: true` annotation. It clarifies the permission mode quirk where delete/move are rejected, which adds real context beyond the annotation booleans. However, it does not elaborate on the recoverability/irreversibility of the write.

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

Conciseness4/5

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

The description is around five sentences and stays dense without fluff. The purpose is front-loaded, the sibling reference comes early, and the operational details are grouped at the end. Minor gains remain possible by trimming the permission-mode detail that is already in the schema.

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

Completeness5/5

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

With no output schema present, the description properly states the return shape ('commit result or a validation, conflict, or protected-branch error'). It covers prerequisites (write permission, selected branch) and edge cases (permission-mode restrictions) — nothing critical is missing for an agent to call the tool correctly.

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 the baseline is 3. The description restates the per-file `action` default and the permission-mode interaction, but that exact information already appears in the `files` parameter's description. It adds no new meaning beyond the schema.

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 and resource: 'Push multiple files in a single commit.' It clearly distinguishes this tool from its sibling `create_or_update_file` by stating the condition for using one over the other (single path vs. multiple files), so an agent can select it correctly without inspecting 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 Guidelines5/5

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

Directs the agent to use `create_or_update_file` when only one path is involved, which is explicit when-to-use vs. when-not-to-use guidance. The atomicity and batch semantics are also stated, so the selection criteria between the two siblings are fully transparent.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zereight/gitlab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server