Skip to main content
Glama
owayo

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

get_review_comments

Retrieve unresolved review comments from GitLab merge requests to identify issues that need attention before code integration.

Instructions

GitLab MRの未解決の指摘事項(コメント)を取得

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • main.py:79-93 (handler)
    The main handler for the 'get_review_comments' tool. It determines the current MR ID, fetches the unresolved comments using get_mr_comments, and formats them into a user-friendly message prompting the user to address them.
    @mcp.tool()
    def get_review_comments() -> str:
        """GitLab MRの未解決の指摘事項(コメント)を取得"""
        mr_id = get_current_mr_id()
    
        mr_comments = get_mr_comments(mr_id=mr_id)
        if mr_comments:
            return f"""
    以下の指摘事項に対応してください。対応後は今後へのアドバイスを出力してください。
    
    {mr_comments}
    """
        else:
            return f"MR #{mr_id} への未解決の指摘事項はありません。"
  • main.py:30-44 (helper)
    Helper function to retrieve the Merge Request ID (MRID) for the current Git branch by calling get_merge_request.
    # カレントのブランチのMRIDを取得
    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が見つかりません。"
  • Core helper function that fetches unresolved, file-associated comments from a GitLab Merge Request discussions using the GitLab API, processes them with process_discussion, and formats into a string.
    def get_mr_comments(mr_id: int) -> str:
        """
        指定したMR IDに関連するMRの指摘事項(コメント)を取得します。
        解決済み(resolved)のコメントは除外されます。
        ファイルに紐づいているコメントのみが取得されます。
    
        Args:
            mr_id (int): Merge Request ID
    
        Returns:
            str: MRへの指摘事項(AIが理解しやすい形式に整形)
    
        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のディスカッション(スレッド)を取得
            discussions = mr.discussions.list()
    
            if not discussions:
                return f"MR #{mr.iid} へのコメントはありません。"
    
            comments: List[str] = []
    
            # 各ディスカッションを処理
            for discussion in discussions:
                # 個々のディスカッション内のノートを処理
                discussion_comments = process_discussion(discussion)
                if discussion_comments:
                    comments.extend(discussion_comments)
    
            if not comments:
                return f"MR #{mr.iid} への未解決の指摘事項はありません。"
    
            return "\n---\n".join(comments)
    
        except Exception as e:
            raise ValueError(f"MRへの指摘事項の取得に失敗しました: {str(e)}")
  • Supporting helper that processes individual discussion threads, filters for unresolved file-associated comments, and formats them with author, location, and body.
    def process_discussion(discussion: Dict[str, Any]) -> List[str]:
        """
        ディスカッション(スレッド)内のノートを処理し、未解決のコメントを抽出します。
        ファイルに紐づいているコメントのみを抽出します。
    
        Args:
            discussion: GitLabディスカッションオブジェクト
    
        Returns:
            List[str]: 未解決のコメント文字列のリスト
        """
        discussion_comments = []
        has_unresolved_notes = False
    
        # ディスカッションにはノートの配列が含まれています
        notes = (
            discussion.attributes.get("notes", [])
            if hasattr(discussion, "attributes")
            else discussion.get("notes", [])
        )
    
        for note in notes:
            # システムノートは除外
            if note.get("system", False):
                continue
    
            # 解決可能で、かつ解決済みのノートは除外
            if note.get("resolvable", False) and note.get("resolved", False):
                continue
    
            # コードとの関連付けがあるか確認
            position = note.get("position", {})
            file_path = position.get("new_path", "") if position else ""
    
            # ファイルに紐づいていないコメントは除外
            if not file_path:
                continue
    
            # ここに到達したノートは未解決かつファイルに紐づいている
            has_unresolved_notes = True
    
            author = note.get("author", {}).get("name", "不明なユーザー")
            body = note.get("body", "")
            line = position.get("new_line", "") if position else ""
    
            location = (
                f" (ファイル: {file_path}, 行: {line})"
                if file_path and line
                else f" (ファイル: {file_path})"
            )
    
            discussion_comments.append(
                f"# 対象: {location}\n- コメント者: {author}\n- コメント:\n```\n{body}\n```"
            )
    
        # ディスカッションに未解決のノートがある場合のみ、そのコメントを返す
        if has_unresolved_notes:
            return discussion_comments
        return []
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. It states the tool retrieves unresolved comments, but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, error handling, or what 'unresolved' specifically means. This leaves significant gaps for an agent to understand how to use it effectively.

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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and appropriately sized for a simple tool with no parameters.

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 has no parameters and no output schema, the description is minimally complete. It specifies what the tool does but lacks details on behavior, output format, or usage context. For a tool with no annotations and no output schema, more information would be helpful, but it's adequate for basic understanding.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline score of 4 is given since the schema fully covers the parameters (none), and the description doesn't need to compensate.

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: 'GitLab MRの未解決の指摘事項(コメント)を取得' translates to 'Get unresolved comments (review comments) for GitLab Merge Requests.' It specifies the verb ('get'), resource ('review comments'), and scope ('unresolved'), but doesn't explicitly differentiate from sibling tools like 'get_review_changes'.

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. It doesn't mention sibling tools, prerequisites, or specific contexts where this tool is preferred over others. Usage is implied by the purpose but not explicitly stated.

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