Skip to main content
Glama

gitlab_get_user_merge_commits

Retrieve merge commits performed by a specific user to track integrated contributions and analyze merge activity for release management.

Instructions

List merge commits where a specific user performed the merge.

Shows commits where the user merged branches (not necessarily the code author). Use this tool to see what merges a user has performed, useful for release management.

Examples:

  • Release management: get_user_merge_commits(user_id=123)

  • Merge activity tracking

  • Integration oversight

For all commits authored by user, use 'gitlab_get_user_commits' instead.

Find all commits that originated from merge requests created by the specified user, tracking their integrated contributions.

Returns merge-related commits with:

  • Commit details: SHA, message, merge info

  • MR context: original MR, review process

  • Integration info: target branch, merge strategy

  • Quality metrics: review feedback, CI results

  • Timeline: development to integration time

Use cases:

  • Track integrated contributions

  • Measure code review effectiveness

  • Analyze development workflows

  • Quality assurance reporting

Parameters:

  • user_id: Numeric user ID

  • username: Username string (use either user_id or username)

  • project_id: Optional project scope filter

  • target_branch: Filter by target branch (e.g., main)

  • since: MRs merged after date (YYYY-MM-DD)

  • until: MRs merged before date (YYYY-MM-DD)

  • include_review_metrics: Include review statistics

  • per_page: Results per page (default: 20)

  • page: Page number (default: 1)

Example: Get merged contributions to main branch

{
  "username": "johndoe",
  "target_branch": "main", 
  "since": "2024-01-01",
  "include_review_metrics": true
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usernameYesUsername string
project_idNoOptional project scope filter
sinceNoCommits after date (YYYY-MM-DD)
untilNoCommits before date (YYYY-MM-DD)
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 primary handler function that implements the gitlab_get_user_merge_commits tool. It validates input arguments (requiring username), extracts optional parameters, and delegates to GitLabClient.get_user_merge_commits() for the actual API call.
    def handle_get_user_merge_commits(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting user's merge commits"""
        username = get_argument(arguments, "username")
        if not username:
            raise ValueError("username is required")
        
        project_id = get_argument(arguments, "project_id")
        since = get_argument(arguments, "since")
        until = get_argument(arguments, "until")
        per_page = get_argument(arguments, "per_page", DEFAULT_PAGE_SIZE)
        page = get_argument(arguments, "page", 1)
        
        return client.get_user_merge_commits(
            username=username,
            project_id=project_id,
            since=since,
            until=until,
            per_page=per_page,
            page=page
        )
  • Pydantic/MCP schema definition for the gitlab_get_user_merge_commits tool, including input parameters, types, descriptions, defaults, and required fields.
    types.Tool(
        name=TOOL_GET_USER_MERGE_COMMITS,
        description=desc.DESC_GET_USER_MERGE_COMMITS,
        inputSchema={
            "type": "object",
            "properties": {
                "username": {"type": "string", "description": "Username string"},
                "project_id": {"type": "string", "description": "Optional project scope filter"},
                "since": {"type": "string", "description": "Merges after date (YYYY-MM-DD)"},
                "until": {"type": "string", "description": "Merges before date (YYYY-MM-DD)"},
                "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": ["username"]
        }
  • Registration of the handler function in the central TOOL_HANDLERS dictionary used by server.call_tool() to dispatch tool calls to the correct handler.
    TOOL_GET_USER_COMMITS: handle_get_user_commits,
    TOOL_GET_USER_MERGE_COMMITS: handle_get_user_merge_commits,
    TOOL_GET_USER_CODE_CHANGES_SUMMARY: handle_get_user_code_changes_summary,
  • Improved tool description and suggested renaming for better LLM usability and reduced ambiguity.
        "gitlab_get_user_merge_commits": {
            "new_name": "gitlab_list_merge_commits_by_user", 
            "description": """List merge commits where a specific user performed the merge.
            
    Shows commits where the user merged branches (not necessarily the code author).
    **Use this tool to see what merges a user has performed, useful for release management.**
    
    Examples:
    - Release management: list_merge_commits_by_user(user_id=123)
    - Merge activity tracking
    - Integration oversight
    
    For all commits authored by user, use 'list_commits_authored_by_user' instead."""
        }
  • Constant definition for the tool name string, used consistently across handler registration, schema, and server.
    TOOL_GET_USER_MERGE_COMMITS = "gitlab_get_user_merge_commits"
    TOOL_GET_USER_CODE_CHANGES_SUMMARY = "gitlab_get_user_code_changes_summary"
    TOOL_GET_USER_SNIPPETS = "gitlab_get_user_snippets"
    
    # User's Comments & Discussions tools
    TOOL_GET_USER_ISSUE_COMMENTS = "gitlab_get_user_issue_comments"
    TOOL_GET_USER_MR_COMMENTS = "gitlab_get_user_mr_comments"
    TOOL_GET_USER_DISCUSSION_THREADS = "gitlab_get_user_discussion_threads"
    TOOL_GET_USER_RESOLVED_THREADS = "gitlab_get_user_resolved_threads"
    
    # Me / Inbox tools
    TOOL_GET_MY_OPEN_MRS = "gitlab_get_my_open_mrs"
    TOOL_GET_MRS_AWAITING_MY_REVIEW = "gitlab_get_mrs_awaiting_my_review"
    TOOL_GET_MY_OPEN_ISSUES = "gitlab_get_my_open_issues"
    TOOL_GET_MY_TODOS_DIGEST = "gitlab_get_my_todos_digest"
    
    # MR Triage & Review Flow tools
    TOOL_FIND_REVIEW_READY_MRS = "gitlab_find_review_ready_mrs"
    TOOL_FIND_STALE_MRS = "gitlab_find_stale_mrs"
    TOOL_FIND_MERGE_BLOCKERS = "gitlab_find_merge_blockers"
    TOOL_AUTOFIX_MR_METADATA = "gitlab_autofix_mr_metadata"
    TOOL_ASSIGN_REVIEWER_ROTATION = "gitlab_assign_reviewer_rotation"
    TOOL_AUTO_MERGE_WHEN_GREEN = "gitlab_auto_merge_when_green"
    TOOL_RESOLVE_DISCUSSIONS_AND_MERGE = "gitlab_resolve_discussions_and_merge"
    
    # Issue ↔ Branch ↔ MR Workflow tools
    TOOL_BOOTSTRAP_ISSUE_BRANCH_MR = "gitlab_bootstrap_issue_branch_mr"
    TOOL_LINK_ISSUE_TO_EXISTING_MR = "gitlab_link_issue_to_existing_mr"
    TOOL_BULK_CLOSE_FIXED_ISSUES = "gitlab_bulk_close_fixed_issues"
    
    # Release & Backports tools
    TOOL_PREPARE_RELEASE_NOTES = "gitlab_prepare_release_notes"
    TOOL_TAG_AND_RELEASE_FROM_MILESTONE = "gitlab_tag_and_release_from_milestone"
    TOOL_BACKPORT_MR_TO_BRANCHES = "gitlab_backport_mr_to_branches"
    TOOL_HOTFIX_FROM_ISSUE = "gitlab_hotfix_from_issue"
    
    # CI/CD & Quality tools
    TOOL_RERUN_FAILED_PIPELINE_SEGMENT = "gitlab_rerun_failed_pipeline_segment"
    TOOL_FLAKY_TEST_DETECTOR = "gitlab_flaky_test_detector"
    TOOL_PIPELINE_RED_ALERTS = "gitlab_pipeline_red_alerts"
    TOOL_DOWNLOAD_LATEST_ARTIFACTS = "gitlab_download_latest_artifacts"
    TOOL_COMPARE_PIPELINE_DURATIONS = "gitlab_compare_pipeline_durations"
    
    # Code & Security tools
    TOOL_SMART_CODE_SEARCH = "gitlab_smart_code_search"
    TOOL_FIND_SUSPECT_COMMITS_SINCE_FAILURE = "gitlab_find_suspect_commits_since_failure"
    TOOL_DEPENDENCY_UPDATE_BATCH = "gitlab_dependency_update_batch"
    TOOL_SECURITY_FINDINGS_DIGEST = "gitlab_security_findings_digest"
    
    # Project Hygiene tools
    TOOL_PRUNE_STALE_BRANCHES = "gitlab_prune_stale_branches"
    TOOL_SYNC_LABELS_POLICY = "gitlab_sync_labels_policy"
    TOOL_AUTO_ARCHIVE_OLD_ISSUES = "gitlab_auto_archive_old_issues"
    TOOL_ENFORCE_MR_RULESET = "gitlab_enforce_mr_ruleset"
    
    # Cross-Project Views tools
    TOOL_GROUP_MR_RISK_RADAR = "gitlab_group_mr_risk_radar"
    TOOL_GROUP_ACTIVITY_SUMMARY = "gitlab_group_activity_summary"
    TOOL_GROUP_OPEN_RELEASE_TRAINS = "gitlab_group_open_release_trains"
    
    # Ownership & Notifications tools
    TOOL_OWNER_MAP_FROM_CODEOWNERS = "gitlab_owner_map_from_codeowners"
    TOOL_NOTIFY_OWNERS_ON_DIRECTORY_CHANGES = "gitlab_notify_owners_on_directory_changes"
    
    # Governance & Compliance tools
    TOOL_MR_TEMPLATE_ENFORCER = "gitlab_mr_template_enforcer"
    TOOL_LICENCE_COMPLIANCE_AUDIT = "gitlab_licence_compliance_audit"
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 effectively describes the tool's behavior: it's a read-only listing tool (implied by 'List'), returns paginated results (via per_page and page parameters), and includes details like commit info, MR context, and quality metrics. However, it doesn't explicitly mention rate limits, authentication needs, or error handling, 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear purpose and usage guidelines, but it becomes verbose with repetitive sections like 'Use cases' and 'Returns merge-related commits with:' that overlap with earlier content. Sentences like 'Find all commits that originated from merge requests created by the specified user' are redundant, reducing efficiency.

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, 6 parameters with 100% schema coverage, and no output schema, the description is mostly complete. It covers purpose, usage, parameters, and behavioral aspects like return details. However, it lacks explicit information on output structure (e.g., format of returned data) and error cases, which would enhance completeness for a tool with no output schema.

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 100%, so the baseline is 3. The description adds value by explaining parameter semantics beyond the schema: it clarifies that 'user_id' and 'username' are alternatives ('use either'), provides context for 'target_branch' (e.g., 'main'), and explains the purpose of 'include_review_metrics' and pagination parameters. However, it lists parameters like 'user_id' not in the schema, causing minor inconsistency.

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: 'List merge commits where a specific user performed the merge.' It specifies the verb ('list'), resource ('merge commits'), and scope ('where a specific user performed the merge'), and distinguishes it from sibling tools by explicitly contrasting with 'gitlab_get_user_commits' for commits authored by the user.

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 guidance on when to use this tool versus alternatives: 'For all commits authored by user, use 'gitlab_get_user_commits' instead.' It also includes use cases like 'release management' and 'merge activity tracking,' and clarifies the tool's specific focus on merges performed by the user, not authored by them.

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