Skip to main content
Glama

gitlab_create_commit

Create atomic commits with multiple file operations (create, update, delete, move) to manage GitLab repository changes via API.

Instructions

Create commit with file changes Returns: New commit details Use when: Making changes via API Supports: Multiple file operations in one commit

Key features:

  • Atomic: All changes or none

  • Multiple files: Up to 100 operations

  • All operations: create, update, delete, move

Example: Add feature with test { "branch": "feature/new-feature", "commit_message": "Add new feature with tests", "actions": [ {"action": "create", "file_path": "src/feature.py", "content": "..."}, {"action": "create", "file_path": "tests/test_feature.py", "content": "..."} ] }

Related tools:

  • gitlab_safe_preview_commit: Preview first

  • gitlab_list_repository_tree: Check existing files

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoProject identifier (auto-detected if not provided) Type: integer OR string Format: numeric ID or 'namespace/project' Optional: Yes - auto-detects from current git repository Examples: - 12345 (numeric ID) - 'gitlab-org/gitlab' (namespace/project path) - 'my-group/my-subgroup/my-project' (nested groups) Note: If in a git repo with GitLab remote, this can be omitted
branchYesTarget branch for commits Type: string Required: Yes Format: Existing branch name Examples: - 'main' (commit to main) - 'feature/add-login' (feature branch) - 'hotfix/security-patch' (hotfix branch) Note: Branch must exist before committing
commit_messageYesCommit message Type: string Required: Yes Format: Conventional commits recommended Structure: - First line: Summary (50-72 chars) - Blank line - Body: Detailed description - Footer: References, breaking changes Examples: 'feat: Add user authentication Implement JWT-based authentication with refresh tokens. Store tokens securely in httpOnly cookies. Closes #123'
actionsYesFile operations for commit Type: array of objects Required: Yes Max items: 100 per commit Structure: { "action": "create" | "update" | "delete" | "move", "file_path": "string (required)", "content": "string (required for create/update)", "encoding": "text" | "base64" (optional, default: text)", "previous_path": "string (required for move)" } Examples: [ { "action": "create", "file_path": "src/config.json", "content": "{"debug": true}" }, { "action": "update", "file_path": "README.md", "content": "# Updated README\n\nNew content here" }, { "action": "delete", "file_path": "old-file.txt" }, { "action": "move", "file_path": "new-location/file.txt", "previous_path": "old-location/file.txt" } ] Use cases: - create: Add new files - update: Modify existing files - delete: Remove files - move: Rename or relocate files
author_emailNoCommit author email Type: string Format: Valid email address Optional: Yes (uses authenticated user's email) Examples: - 'john.doe@example.com' - 'bot@automated-system.com' Use case: Override for automated commits
author_nameNoCommit author name Type: string Format: Any string Optional: Yes (uses authenticated user's name) Examples: - 'John Doe' - 'Automated Bot' - 'CI System' Use case: Override for automated commits

Implementation Reference

  • The main handler function that executes the gitlab_create_commit tool logic. It extracts parameters, resolves the project ID, and calls the GitLab client's create_commit method.
    def handle_create_commit(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle creating a commit with multiple file changes"""
        project_id = require_project_id(client, arguments)
        branch = require_argument(arguments, "branch")
        commit_message = require_argument(arguments, "commit_message")
        actions = require_argument(arguments, "actions")
        
        author_email = get_argument(arguments, "author_email")
        author_name = get_argument(arguments, "author_name")
        
        return client.create_commit(project_id, branch, commit_message, actions, author_email, author_name)
  • The input schema and tool definition for gitlab_create_commit, defining parameters like project_id, branch, commit_message, actions array, and optional author details.
        name=TOOL_CREATE_COMMIT,
        description=desc.DESC_CREATE_COMMIT,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": desc.DESC_PROJECT_ID},
                "branch": {"type": "string", "description": desc.DESC_BRANCH},
                "commit_message": {"type": "string", "description": desc.DESC_COMMIT_MESSAGE},
                "actions": {
                    "type": "array",
                    "description": desc.DESC_ACTIONS,
                    "items": {
                        "type": "object",
                        "properties": {
                            "action": {"type": "string", "enum": ["create", "update", "delete", "move"]},
                            "file_path": {"type": "string"},
                            "content": {"type": "string"},
                            "previous_path": {"type": "string"},
                            "encoding": {"type": "string", "enum": ["text", "base64"], "default": "text"}
                        },
                        "required": ["action", "file_path"]
                    }
                },
                "author_email": {"type": "string", "description": desc.DESC_AUTHOR_EMAIL},
                "author_name": {"type": "string", "description": desc.DESC_AUTHOR_NAME}
            },
            "required": ["branch", "commit_message", "actions"]
        }
    ),
  • Registration of the tool name to its handler function in the TOOL_HANDLERS dictionary, used by the server's call_tool dispatcher.
    TOOL_CREATE_COMMIT: handle_create_commit,
    TOOL_CHERRY_PICK_COMMIT: handle_cherry_pick_commit,
  • Constant defining the tool name string used throughout the codebase for consistency.
    TOOL_CREATE_COMMIT = "gitlab_create_commit"
Behavior4/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does well by explaining key behavioral traits: atomic nature ('All changes or none'), operation limits ('Up to 100 operations'), supported action types, and return value ('Returns: New commit details'). However, it doesn't mention authentication requirements, rate limits, or error handling scenarios.

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 well-structured with clear sections (description, returns, use when, supports, key features, example, related tools) and front-loaded with the core purpose. While slightly longer than minimal, every section adds value. The example is particularly helpful but makes the description less concise than ideal.

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?

For a mutation tool with 6 parameters, 100% schema coverage, but no annotations or output schema, the description does quite well. It covers purpose, usage context, behavioral traits, and provides a concrete example. The main gap is the lack of output details (only 'New commit details' is mentioned without structure), but given the complexity and schema richness, this is reasonably complete.

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?

With 100% schema description coverage, the baseline is 3. The description adds minimal parameter semantics beyond the schema - it mentions 'Multiple files: Up to 100 operations' which aligns with the schema's max items constraint, and provides an example showing the actions array structure. However, it doesn't add significant meaning beyond what's already documented in the comprehensive schema descriptions.

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 tool's purpose with specific verbs ('Create commit with file changes') and distinguishes it from siblings by mentioning atomic operations and multiple file capabilities. It explicitly differentiates from gitlab_safe_preview_commit and gitlab_list_repository_tree in the 'Related tools' section.

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?

The description provides explicit usage guidance with 'Use when: Making changes via API' and offers clear alternatives in the 'Related tools' section (gitlab_safe_preview_commit for previewing first, gitlab_list_repository_tree for checking existing files). This gives the agent specific when-to-use and when-not-to-use information.

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/Vijay-Duke/mcp-gitlab'

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