Skip to main content
Glama
owayo

https://github.com/owayo/gitlab-mcp-server

get_review_changes

Retrieve file differences in GitLab merge requests to identify code changes for review and collaboration.

Instructions

GitLab MRで修正したファイルの差分を取得

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • main.py:63-77 (handler)
    The handler function for the 'get_review_changes' tool, registered via @mcp.tool(). It gets the current MR ID and uses get_mr_changes to fetch the review changes diff, formatting it for review.
    @mcp.tool()
    def get_review_changes() -> str:
        """GitLab MRで修正したファイルの差分を取得"""
        mr_id = get_current_mr_id()
    
        changes = get_mr_changes(mr_id=mr_id)
        if changes:
            return f"""
    以下の変更について @Codebase を考慮してレビューし、コードの問題点や改善点を出してください。
    
    {changes}
    """
        else:
            return "変更内容を取得できません。"
  • Helper function called by the tool handler to retrieve MR details and compute the base SHA, then delegate to get_diff_from_base for the actual diff.
    def get_mr_changes(mr_id: int) -> str:
        """
        指定したMR IDに関連するMRのベースコミット(base_sha)から現在のローカルの状態までの差分を取得します。
        リモートの差分ではなく、ローカルの最新状態との差分を取得します。
    
        Args:
            mr_id (int): Merge Request ID
    
        Returns:
            str: MRのベースコミットから現在のローカル状態までの変更内容(差分)
    
        Raises:
            ValueError: 変更内容の取得に失敗した場合
        """
        try:
            project = get_gitlab_project()
    
            # MRを取得
            try:
                mr: MergeRequest = project.mergerequests.get(mr_id)
            except gitlab.exceptions.GitlabGetError:
                return f"MR ID #{mr_id} が見つかりません。"
    
            # MRのdiff_refsからbase_shaを取得
            if not hasattr(mr, "diff_refs") or not mr.diff_refs:
                return f"MR #{mr.iid} の差分情報が取得できません。"
    
            base_sha: Optional[str] = mr.diff_refs.get("base_sha")
            if not base_sha:
                return f"MR #{mr.iid} のベースコミットが特定できません。"
    
            # ローカルリポジトリでbase_shaからの差分を取得
            try:
                diff_output = get_diff_from_base(base_sha)
                if not diff_output or diff_output == "変更されたファイルはありません。":
                    return f"MR #{mr.iid} (ベースコミット: {base_sha}) からの変更はありません。"
    
                return diff_output
            except Exception as e:
                return f"ローカルリポジトリからの差分取得に失敗しました: {str(e)}"
    
        except Exception as e:
            raise ValueError(f"MRの変更内容の取得に失敗しました: {str(e)}")
  • Core helper that performs the actual Git diff computation from the base SHA to the current local repository state, formatting the changes per file.
    def get_diff_from_base(base_sha: str) -> str:
        """
        指定されたベースSHAから現在の状態までの差分を取得します。
        ローカルリポジトリの変更を含みます。
    
        Args:
            base_sha (str): 比較の基点となるコミットのSHA
    
        Returns:
            str: ベースSHAから現在までの差分
    
        Raises:
            ValueError: 差分の取得に失敗した場合
        """
        try:
            repo_path = get_git_repo_path()
            repo = git.Repo(repo_path)
    
            # 変更されたファイルのリストを取得
            change_details = []
    
            # リポジトリの現在の状態(インデックスと作業ディレクトリ)をベースSHAと比較
            diff_index = repo.git.diff(base_sha, name_status=True).strip()
    
            if not diff_index:
                return "変更されたファイルはありません。"
    
            # 変更されたファイルごとに詳細な差分を取得
            for line in diff_index.split("\n"):
                if not line:
                    continue
    
                parts = line.split("\t")
                if len(parts) < 2:
                    continue
    
                change_type_code = parts[0]
                file_path = parts[1]
    
                # 変更の種類を判定
                change_type = "変更"
                if change_type_code.startswith("A"):
                    change_type = "新規追加"
                elif change_type_code.startswith("D"):
                    change_type = "削除"
                elif change_type_code.startswith("R"):
                    change_type = "名前変更"
    
                # ファイルの差分を取得
                try:
                    file_diff = repo.git.diff(base_sha, file_path, unified=3)
                    change_details.append(
                        f"# ファイル: {file_path} ({change_type})\n```diff\n{file_diff}\n```"
                    )
                except Exception as e:
                    # 特定のファイルの差分取得に失敗した場合はエラーメッセージを追加
                    change_details.append(
                        f"# ファイル: {file_path} ({change_type})\n```\n差分の取得に失敗しました: {str(e)}\n```"
                    )
    
            return "\n\n".join(change_details)
    
        except Exception as e:
            raise ValueError(f"差分の取得に失敗しました: {str(e)}")
  • main.py:31-44 (helper)
    Internal helper used by the tool to get the current MR ID from the branch name.
    def get_current_mr_id() -> int:
        """
        現在のブランチのMRIDを取得します。
    
        Returns:
            int: 現在のブランチのMRID
        """
        branch_name = get_current_branch()
        mr = get_merge_request(branch_name)
        if mr:
            return mr.iid
        else:
            return "現在のブランチに関連するMerge Requestが見つかりません。"
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (gets file differences) but doesn't describe any behavioral traits: no information about authentication requirements, rate limits, pagination, error conditions, or what format the differences are returned in. For a tool with zero annotation coverage, this is a significant gap in behavioral transparency.

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 a single, efficient sentence in Japanese that directly states the tool's purpose. There's no wasted verbiage or unnecessary elaboration. However, it could be slightly improved by being front-loaded with more complete information about the tool's behavior and usage context.

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?

Given the tool has no annotations and no output schema, the description is incomplete. It doesn't explain what format the differences are returned in (unified diff? JSON? raw git diff?), what authentication is required, or any error conditions. For a tool that presumably interacts with GitLab's API, this leaves significant gaps in understanding how to properly use it.

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?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation (none). The description doesn't need to compensate for any parameter gaps. The baseline for 0 parameters with full schema coverage is 4, as there's no parameter semantics burden on the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'gets differences of modified files in GitLab MR' which provides a basic purpose (verb+resource). However, it doesn't distinguish this from sibling tools like 'get_review_comments' - both appear to retrieve MR-related information but with different data types. The purpose is clear but lacks sibling differentiation.

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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention when this should be used instead of 'get_review_comments' or 'get_pipeline_failed_jobs', nor does it provide any context about prerequisites, timing, or constraints. The agent receives no usage guidance beyond the basic purpose.

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

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