Skip to main content
Glama

create_merge_request

Create a new merge request in GitLab to propose code changes from a source branch to a target branch, with options for title, description, assignee, and reviewers.

Instructions

建立新的 Merge Request

Args: project_id: 專案 ID 或路徑 source_branch: 來源分支 target_branch: 目標分支 title: MR 標題 description: MR 描述 assignee_id: 指派人 ID reviewer_ids: 審核者 ID 列表(逗號分隔,如 "1,2,3")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
source_branchYes
target_branchYes
titleYes
descriptionNo
assignee_idNo
reviewer_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The MCP tool registration and handler logic for 'create_merge_request', which parses input and calls the client.
    @mcp.tool()
    def create_merge_request(project_id: int | str, source_branch: str,
                             target_branch: str, title: str,
                             description: str = None, assignee_id: int = None,
                             reviewer_ids: str = None) -> str:
        """建立新的 Merge Request
    
        Args:
            project_id: 專案 ID 或路徑
            source_branch: 來源分支
            target_branch: 目標分支
            title: MR 標題
            description: MR 描述
            assignee_id: 指派人 ID
            reviewer_ids: 審核者 ID 列表(逗號分隔,如 "1,2,3")
        """
        try:
            v = GitLabValidator.validate_merge_request_data({
                "source_branch": source_branch,
                "target_branch": target_branch,
                "title": title,
            })
            if not v.is_valid:
                return "驗證失敗:\n" + "\n".join(v.errors)
    
            # 解析逗號分隔的 reviewer_ids
            parsed_reviewer_ids = None
            if reviewer_ids:
                try:
                    parsed_reviewer_ids = [int(x.strip()) for x in reviewer_ids.split(",")]
                except ValueError:
                    return "reviewer_ids 格式錯誤,請使用逗號分隔的數字(如 1,2,3)"
    
            client = get_client()
            mr = client.create_merge_request(
                project_id, source_branch, target_branch, title,
                description=description, assignee_id=assignee_id,
                reviewer_ids=parsed_reviewer_ids
            )
            return f"✓ MR 已建立: !{mr['iid']} — {mr['title']}\n網址: {mr.get('web_url', '')}"
        except GitLabAPIError as e:
            return f"建立 MR 失敗: {str(e)}"
  • The actual implementation of the 'create_merge_request' method within the GitLab client, which performs the API request.
    def create_merge_request(
        self,
        project_id: int | str,
        source_branch: str,
        target_branch: str,
        title: str,
        description: str = None,
        assignee_id: int = None,
        reviewer_ids: list[int] = None,
    ) -> dict:
        """POST /projects/:id/merge_requests"""
        pid = self._resolve_project_id(project_id)
        data = {
            "source_branch": source_branch,
            "target_branch": target_branch,
            "title": title,
        }
        if description is not None:
            data["description"] = description
        if assignee_id is not None:
            data["assignee_id"] = assignee_id
        if reviewer_ids is not None:
            data["reviewer_ids"] = reviewer_ids
        return self._post_json(f"/projects/{pid}/merge_requests", data=data)
    
    def update_merge_request(
        self, project_id: int | str, mr_iid: int, **kwargs
    ) -> dict:
        """PUT /projects/:id/merge_requests/:iid
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While '建立新的 Merge Request' implies a write/mutation operation, the description doesn't address permissions required, side effects (e.g., notifications sent), error conditions, or what happens on success (e.g., MR ID returned). The parameter list adds some context but lacks behavioral details like rate limits or idempotency.

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 the purpose statement, followed by a structured parameter list. However, the parameter explanations are minimal (single phrases), and the overall text could be more efficient by integrating usage context. It avoids redundancy but feels slightly sparse rather than optimally concise.

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?

Given the tool's complexity (7 parameters, mutation operation) and lack of annotations, the description is moderately complete. It covers the core action and parameters but misses behavioral details (e.g., permissions, notifications). The presence of an output schema (not provided here) might help, but without it, the description should ideally mention what's returned (e.g., MR object or ID).

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It provides a clear parameter list with brief explanations in Chinese (e.g., '專案 ID 或路徑' for project_id, '來源分支' for source_branch), adding meaningful semantics beyond the schema's generic titles. However, it doesn't explain format constraints (e.g., what constitutes a valid project_id path) or dependencies between 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 description clearly states the tool's purpose: '建立新的 Merge Request' (create a new Merge Request). It specifies the verb (create/建立) and resource (Merge Request), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'merge_merge_request' or 'update_merge_request', which would require more specific language about when to use each.

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?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'merge_merge_request' (to complete a merge), 'update_merge_request' (to modify an existing one), and 'list_merge_requests' (to view existing ones), there's no indication of prerequisites, appropriate contexts, or distinctions between creation and other merge request operations.

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

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