Skip to main content
Glama

gitlab_get_merge_request_approvals

Check merge request approval status to determine if it can be merged. Shows required approvals, current approvals, and who approved.

Instructions

Check MR approval status Returns: Approval requirements and current state Use when: Checking if MR can be merged Shows: Required approvals, who approved

Example response: { "approvals_required": 2, "approvals_left": 1, "approved_by": [ {"user": {"username": "johndoe"}} ], "approval_rules": [...] }

Related tools:

  • gitlab_approve_merge_request: Add approval

  • gitlab_merge_merge_request: Merge when ready

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

Implementation Reference

  • The main handler function for the tool. It resolves the project ID (auto-detecting from git if not provided), requires the mr_iid parameter, and delegates to the GitLabClient's get_merge_request_approvals method.
    def handle_get_merge_request_approvals(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting merge request approvals"""
        project_id = require_project_id(client, arguments)
        mr_iid = require_argument(arguments, "mr_iid")
        
        return client.get_merge_request_approvals(project_id, mr_iid)
  • Pydantic/MCP schema definition for the tool, including input parameters (project_id optional, mr_iid required) with descriptions and validation.
        name=TOOL_GET_MR_APPROVALS,
        description=desc.DESC_GET_MR_APPROVALS,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": desc.DESC_PROJECT_ID},
                "mr_iid": {"type": "integer", "description": desc.DESC_MR_IID}
            },
            "required": ["mr_iid"]
        }
    ),
  • Registration of the handler function in the central TOOL_HANDLERS dictionary, mapping the tool name to its implementation.
    TOOL_GET_MR_APPROVALS: handle_get_merge_request_approvals,
  • Detailed description string for the tool used in schema definitions.
    DESC_GET_MR_APPROVALS = """Check MR approval status
    Returns: Approval requirements and current state
    Use when: Checking if MR can be merged
    Shows: Required approvals, who approved
    
    Example response:
    {
      "approvals_required": 2,
      "approvals_left": 1,
      "approved_by": [
        {"user": {"username": "johndoe"}}
      ],
      "approval_rules": [...]
    }
    
    Related tools:
    - gitlab_approve_merge_request: Add approval
    - gitlab_merge_merge_request: Merge when ready"""
  • Constant definition for the tool name string, used consistently across the codebase for registration and references.
    TOOL_GET_MR_APPROVALS = "gitlab_get_merge_request_approvals"
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 of behavioral disclosure. It clearly indicates this is a read operation ('Check', 'Returns', 'Shows') and provides a detailed example response showing the data structure. However, it doesn't mention potential errors, rate limits, or authentication requirements.

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 perfectly structured with clear sections: purpose, returns, usage, example response, and related tools. Every sentence earns its place, and the information is front-loaded with the core purpose first.

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 read-only tool with no output schema, the description provides excellent context including a detailed example response. It covers purpose, usage, and relationships to other tools. The main gap is the lack of error handling or edge case information, but otherwise it's quite 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?

The schema description coverage is 100%, providing comprehensive documentation for both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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 a specific verb ('Check') and resource ('MR approval status'), and distinguishes it from siblings by showing what it returns. It explicitly differentiates from gitlab_approve_merge_request and gitlab_merge_merge_request, making its read-only nature clear.

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: Checking if MR can be merged' and lists related tools with their purposes. This gives clear context for when to use this tool versus alternatives like approving or merging.

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