Skip to main content
Glama

gitlab_get_user_code_changes_summary

Analyze a developer's code contributions by retrieving lines added/removed, files changed, and language breakdowns over a specified time period for productivity reporting and capacity planning.

Instructions

Get lines added/removed and files changed by user over period

Generate comprehensive statistics about a user's code contributions including quantitative metrics and impact analysis.

Returns code change summary with:

  • Volume metrics: lines added, removed, net change

  • File statistics: files created, modified, deleted

  • Language breakdown: contributions by file type

  • Project distribution: changes across repositories

  • Trend analysis: velocity over time periods

Use cases:

  • Development productivity analysis

  • Code contribution reporting

  • Team capacity planning

  • Performance review data

Parameters:

  • user_id: Numeric user ID

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

  • project_id: Optional project scope filter

  • since: Analysis period start (YYYY-MM-DD)

  • until: Analysis period end (YYYY-MM-DD)

  • include_languages: Break down by programming language

  • include_trends: Include time-series trend data

  • granularity: Data granularity (daily, weekly, monthly)

Example: Get quarterly code change summary

{
  "username": "johndoe",
  "since": "2024-01-01", 
  "until": "2024-03-31",
  "include_languages": true,
  "granularity": "weekly"
}

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

Implementation Reference

  • The MCP tool handler function that parses arguments, validates username is provided, and calls the GitLabClient method to fetch the user's code changes summary.
    def handle_get_user_code_changes_summary(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting user's code changes summary"""
        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)
        
        return client.get_user_code_changes_summary(
            username=username,
            project_id=project_id,
            since=since,
            until=until,
            per_page=per_page
        )
  • The input schema definition for the tool, specifying parameters like username (required), project_id, since, until with defaults and types.
    types.Tool(
        name=TOOL_GET_USER_CODE_CHANGES_SUMMARY,
        description=desc.DESC_GET_USER_CODE_CHANGES_SUMMARY,
        inputSchema={
            "type": "object",
            "properties": {
                "username": {"type": "string", "description": "Username string"},
                "project_id": {"type": "string", "description": "Optional project scope filter"},
                "since": {"type": "string", "description": "Changes after date (YYYY-MM-DD)", "default": "30 days ago"},
                "until": {"type": "string", "description": "Changes before date (YYYY-MM-DD)", "default": "today"}
            },
            "required": ["username"]
        }
    ),
  • The TOOL_HANDLERS dictionary maps the tool name constant to its handler function, used by the MCP server to dispatch tool calls.
    TOOL_HANDLERS = {
        # List tools
        TOOL_LIST_PROJECTS: handle_list_projects,
        TOOL_LIST_ISSUES: handle_list_issues,
        TOOL_LIST_MRS: handle_list_merge_requests,
        TOOL_LIST_BRANCHES: handle_list_branches,
        TOOL_LIST_PIPELINES: handle_list_pipelines,
        TOOL_LIST_USER_EVENTS: handle_get_user_events,
        TOOL_LIST_COMMITS: handle_get_commits,
        TOOL_LIST_REPOSITORY_TREE: handle_get_repository_tree,
        TOOL_LIST_TAGS: handle_get_tags,
        TOOL_LIST_RELEASES: handle_list_releases,
        TOOL_LIST_PROJECT_MEMBERS: handle_get_project_members,
        TOOL_LIST_PROJECT_HOOKS: handle_get_project_hooks,
        TOOL_LIST_GROUPS: handle_list_groups,
        TOOL_LIST_GROUP_PROJECTS: handle_list_group_projects,
        TOOL_LIST_SNIPPETS: handle_list_snippets,
        TOOL_LIST_PIPELINE_JOBS: handle_list_pipeline_jobs,
        TOOL_LIST_PROJECT_JOBS: handle_list_project_jobs,
    
        # Get tools
        TOOL_GET_PROJECT: handle_get_project,
        TOOL_GET_CURRENT_PROJECT: handle_get_current_project,
        TOOL_GET_MR_NOTES: handle_get_merge_request_notes,
        TOOL_GET_CURRENT_USER: handle_get_current_user,
        TOOL_GET_USER: handle_get_user,
        TOOL_GET_GROUP: handle_get_group,
        TOOL_GET_SNIPPET: handle_get_snippet,
        TOOL_DOWNLOAD_JOB_ARTIFACT: handle_download_job_artifact,
        TOOL_GET_ISSUE: handle_get_issue,
        TOOL_GET_MERGE_REQUEST: handle_get_merge_request,
        TOOL_GET_FILE_CONTENT: handle_get_file_content,
        TOOL_GET_COMMIT: handle_get_commit,
        TOOL_GET_COMMIT_DIFF: handle_get_commit_diff,
        TOOL_GET_MR_APPROVALS: handle_get_merge_request_approvals,
        TOOL_GET_MR_DISCUSSIONS: handle_get_merge_request_discussions,
        TOOL_GET_MR_CHANGES: handle_get_merge_request_changes,
    
        # Action tools
        TOOL_CREATE_SNIPPET: handle_create_snippet,
        TOOL_UPDATE_SNIPPET: handle_update_snippet,
        TOOL_UPDATE_MR: handle_update_merge_request,
        TOOL_CLOSE_MR: handle_close_merge_request,
        TOOL_MERGE_MR: handle_merge_merge_request,
        TOOL_REBASE_MR: handle_rebase_merge_request,
        TOOL_APPROVE_MR: handle_approve_merge_request,
        TOOL_ADD_ISSUE_COMMENT: handle_add_issue_comment,
        TOOL_ADD_MR_COMMENT: handle_add_merge_request_comment,
        TOOL_RESOLVE_DISCUSSION: handle_resolve_discussion,
        TOOL_CREATE_COMMIT: handle_create_commit,
        TOOL_CHERRY_PICK_COMMIT: handle_cherry_pick_commit,
        TOOL_COMPARE_REFS: handle_compare_refs,
    
        # Search tools
        TOOL_SEARCH_PROJECTS: handle_search_projects,
        TOOL_SEARCH_IN_PROJECT: handle_search_in_project,
    
        # AI and Advanced Tools
        TOOL_SUMMARIZE_MR: handle_summarize_merge_request,
        TOOL_SUMMARIZE_ISSUE: handle_summarize_issue,
        TOOL_SUMMARIZE_PIPELINE: handle_summarize_pipeline,
        TOOL_SMART_DIFF: handle_smart_diff,
        TOOL_SAFE_PREVIEW_COMMIT: handle_safe_preview_commit,
        TOOL_BATCH_OPERATIONS: handle_batch_operations,
        
        # Job and Artifact handlers
        TOOL_LIST_PIPELINE_JOBS: handle_list_pipeline_jobs,
        TOOL_DOWNLOAD_JOB_ARTIFACT: handle_download_job_artifact,
        TOOL_LIST_PROJECT_JOBS: handle_list_project_jobs,
        
        # User & Profile handlers
        TOOL_SEARCH_USER: handle_search_user,
        TOOL_GET_USER_DETAILS: handle_get_user_details,
        TOOL_GET_MY_PROFILE: handle_get_my_profile,
        TOOL_GET_USER_CONTRIBUTIONS_SUMMARY: handle_get_user_contributions_summary,
        TOOL_GET_USER_ACTIVITY_FEED: handle_get_user_activity_feed,
        
        # User's Issues & MRs handlers
        TOOL_GET_USER_OPEN_MRS: handle_get_user_open_mrs,
        TOOL_GET_USER_REVIEW_REQUESTS: handle_get_user_review_requests,
        TOOL_GET_USER_OPEN_ISSUES: handle_get_user_open_issues,
        TOOL_GET_USER_REPORTED_ISSUES: handle_get_user_reported_issues,
        TOOL_GET_USER_RESOLVED_ISSUES: handle_get_user_resolved_issues,
        
        # User's Code & Commits handlers  
        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,
        TOOL_GET_USER_SNIPPETS: handle_get_user_snippets,
        
        # User's Comments & Discussions handlers
        TOOL_GET_USER_ISSUE_COMMENTS: handle_get_user_issue_comments,
        TOOL_GET_USER_MR_COMMENTS: handle_get_user_mr_comments,
        TOOL_GET_USER_DISCUSSION_THREADS: handle_get_user_discussion_threads,
        TOOL_GET_USER_RESOLVED_THREADS: handle_get_user_resolved_threads,
    }
  • Constant definition for the tool name string, used across schema, handlers, and registration.
    TOOL_GET_USER_CODE_CHANGES_SUMMARY = "gitlab_get_user_code_changes_summary"
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the tool's behavioral traits by describing what it returns (code change summary with specific metrics) and implies it's a read-only analysis tool. However, it doesn't mention rate limits, authentication requirements, pagination behavior (though 'per_page' is in schema), or whether it's computationally expensive for large date ranges.

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 appropriately front-loaded with the core purpose, but contains some redundancy (e.g., 'Get lines added/removed' then 'Generate comprehensive statistics'). The 'Use cases' section is helpful but could be more concise. The example is valuable but lengthy. Overall, it's somewhat verbose but well-structured with clear sections.

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 5 parameters with 100% schema coverage but no annotations and no output schema, the description does a good job explaining what the tool returns and its use cases. It provides substantial context about the analysis capabilities and metrics. However, it doesn't fully compensate for the lack of output schema by detailing the exact structure of returned data, and there's parameter inconsistency between description and 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 baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it clarifies that 'user_id' and 'username' are alternatives ('use either'), explains what 'include_languages' and 'include_trends' do, defines 'granularity' options, and provides a comprehensive example. However, it mentions parameters not in the schema (user_id, include_languages, include_trends, granularity), creating some 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: 'Get lines added/removed and files changed by user over period' and 'Generate comprehensive statistics about a user's code contributions'. It distinguishes from siblings like 'gitlab_get_user_commits' (which lists commits) and 'gitlab_get_user_contributions_summary' (which might be broader) by focusing specifically on code change metrics with quantitative analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context with 'Use cases' section listing development productivity analysis, code contribution reporting, team capacity planning, and performance review data. It also includes an example showing typical parameter usage. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings.

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