Skip to main content
Glama

gitlab_get_merge_request_discussions

Retrieve threaded discussion threads from GitLab merge requests to read and understand code review comments with structured conversation flow.

Instructions

Get MR discussion threads Returns: Threaded discussions with replies Use when: Reading code review comments Better than notes: Shows thread structure

Example response: [{ "id": "abc123...", "notes": [{ "body": "Should we use a different approach here?", "author": {"username": "reviewer"}, "resolvable": true, "resolved": false }, { "body": "Good point, let me refactor this.", "author": {"username": "author"} }] }]

Related tools:

  • gitlab_resolve_discussion: Mark resolved

  • gitlab_add_merge_request_comment: Reply

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
mr_iidYesMerge request number (IID - Internal ID) Type: integer Format: Project-specific MR number (without !) Required: Yes Examples: - 456 (for MR !456) - 7890 (for MR !7890) How to find: Look at MR URL or title - URL: https://gitlab.com/group/project/-/merge_requests/456 → use 456 - Title: "Add new feature (!456)" → use 456 Note: This is NOT the global MR ID
per_pageNoNumber of results per page Type: integer Range: 1-100 Default: 20 Example: 50 (for faster browsing) Tip: Use smaller values (10-20) for detailed operations, larger (50-100) for listing
pageNoPage number for pagination Type: integer Range: ≥1 Default: 1 Example: 3 (to get the third page of results) Note: Use with per_page to navigate large result sets

Implementation Reference

  • The core handler function that implements the gitlab_get_merge_request_discussions tool. It extracts parameters (project_id via detection or arg, mr_iid required, optional pagination), then delegates to GitLabClient.get_merge_request_discussions().
    def handle_get_merge_request_discussions(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting merge request discussions"""
        project_id = require_project_id(client, arguments)
        mr_iid = require_argument(arguments, "mr_iid")
        per_page = get_argument(arguments, "per_page", DEFAULT_PAGE_SIZE)
        page = get_argument(arguments, "page", 1)
        
        return client.get_merge_request_discussions(project_id, mr_iid, per_page, page)
  • Registers the handler function in the central TOOL_HANDLERS dictionary used by server.py to dispatch tool calls.
    TOOL_GET_MR_DISCUSSIONS: handle_get_merge_request_discussions,
  • Defines the tool schema including inputSchema with properties for project_id, mr_iid (required), per_page, page, and references description from tool_descriptions.
        name=TOOL_GET_MR_DISCUSSIONS,
        description=desc.DESC_GET_MR_DISCUSSIONS,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": desc.DESC_PROJECT_ID},
                "mr_iid": {"type": "integer", "description": desc.DESC_MR_IID},
                "per_page": {"type": "integer", "description": desc.DESC_PER_PAGE, "default": DEFAULT_PAGE_SIZE, "minimum": 1, "maximum": MAX_PAGE_SIZE},
                "page": {"type": "integer", "description": desc.DESC_PAGE_NUMBER, "default": 1, "minimum": 1}
            },
            "required": ["mr_iid"]
        }
    ),
  • Constant defining the exact tool name string used across the codebase for references, registrations, and tests.
    TOOL_GET_MR_DISCUSSIONS = "gitlab_get_merge_request_discussions"
  • Registers the tool schema directly in the MCP server's list_tools() handler, making it available to MCP clients.
        name="gitlab_get_merge_request_discussions",
        description=desc.DESC_GET_MR_DISCUSSIONS,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": desc.DESC_PROJECT_ID},
                "mr_iid": {"type": "integer", "description": desc.DESC_MR_IID},
                "per_page": {"type": "integer", "description": desc.DESC_PER_PAGE, "default": DEFAULT_PAGE_SIZE, "minimum": 1, "maximum": MAX_PAGE_SIZE},
                "page": {"type": "integer", "description": desc.DESC_PAGE_NUMBER, "default": 1, "minimum": 1}
            },
            "required": ["mr_iid"]
        }
    ),
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns threaded discussions with replies (output format), and the example response shows structure including resolvable status. However, it doesn't mention pagination behavior, rate limits, or authentication requirements, leaving some gaps.

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 purpose, usage guidance, example, and related tools sections. It's appropriately sized, but the example response is quite detailed and could be summarized more concisely. Most sentences earn their place, though some formatting could be tighter.

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?

Given no annotations and no output schema, the description does a good job explaining what the tool returns (threaded discussions with replies) and when to use it. The example response provides concrete output structure. However, it doesn't cover error cases, authentication needs, or pagination behavior, which would be helpful for a read operation.

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 description coverage is 100%, so the schema fully documents all parameters. The description adds no parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

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 verb ('Get') and resource ('MR discussion threads'), and distinguishes it from sibling tools like 'gitlab_get_merge_request_notes' by emphasizing thread structure. The opening line 'Get MR discussion threads' is direct and unambiguous.

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 explicitly provides usage guidance with 'Use when: Reading code review comments' and 'Better than notes: Shows thread structure', which differentiates it from the 'gitlab_get_merge_request_notes' sibling tool. It also lists related tools for follow-up actions, offering clear alternatives.

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