Skip to main content
Glama

gitlab_get_user_discussion_threads

Retrieve all discussion threads initiated by a specific user across GitLab issues and merge requests to analyze contributions, track communication patterns, and assess collaboration impact.

Instructions

Get all discussion threads started by a user

Find all discussion threads initiated by the specified user across issues, merge requests, and other collaborative contexts.

Returns discussion thread information with:

  • Thread details: initial message, topic, context

  • Engagement: replies, participants, resolution

  • Origin: issue/MR association, project context

  • Timeline: creation, activity, resolution dates

  • Impact: influence on decisions and outcomes

Use cases:

  • Leadership and initiative tracking

  • Communication effectiveness analysis

  • Knowledge sharing assessment

  • Team collaboration insights

Parameters:

  • user_id: Numeric user ID

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

  • project_id: Optional project scope filter

  • context_type: Filter by context (Issue, MergeRequest, all)

  • status: Filter by resolution status (active, resolved, all)

  • since: Threads started after date (YYYY-MM-DD)

  • until: Threads started before date (YYYY-MM-DD)

  • sort: Sort order (created, activity, resolution)

  • per_page: Results per page (default: 20)

  • page: Page number (default: 1)

Example: Get active discussion threads

{
  "username": "johndoe",
  "status": "active",
  "sort": "activity"
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usernameYesUsername string
project_idNoOptional project scope filter
thread_statusNoFilter by thread status
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 core logic of the 'gitlab_get_user_discussion_threads' tool. It parses input arguments, validates the required 'username', and calls the underlying GitLabClient method to fetch the discussion threads.
    def handle_get_user_discussion_threads(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting user's discussion threads"""
        username = get_argument(arguments, "username")
        if not username:
            raise ValueError("username is required")
        
        project_id = get_argument(arguments, "project_id")
        thread_status = get_argument(arguments, "thread_status")
        per_page = get_argument(arguments, "per_page", DEFAULT_PAGE_SIZE)
        page = get_argument(arguments, "page", 1)
        
        return client.get_user_discussion_threads(
            username=username,
            project_id=project_id,
            thread_status=thread_status,
            per_page=per_page,
            page=page
        )
  • The input schema definition for the tool, specifying parameters like username (required), optional project_id, thread_status enum, pagination options.
    types.Tool(
        name=TOOL_GET_USER_DISCUSSION_THREADS,
        description=desc.DESC_GET_USER_DISCUSSION_THREADS,
        inputSchema={
            "type": "object",
            "properties": {
                "username": {"type": "string", "description": "Username string"},
                "project_id": {"type": "string", "description": "Optional project scope filter"},
                "thread_status": {"type": "string", "description": "Filter by thread status", "enum": ["resolved", "unresolved"]},
                "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"]
        }
    ),
  • The TOOL_HANDLERS dictionary registers the tool name to its handler function. The server uses this mapping to dispatch tool calls to the correct handler.
    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 defining the exact tool name string used throughout the codebase for consistency.
    TOOL_GET_USER_DISCUSSION_THREADS = "gitlab_get_user_discussion_threads"
Behavior3/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 discloses that the tool returns discussion thread information with details like engagement, origin, timeline, and impact, which adds behavioral context beyond basic functionality. However, it does not mention important behavioral traits such as authentication requirements, rate limits, error handling, or whether this is a read-only operation (though 'Get' implies it).

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 clear sections (purpose, returns, use cases, parameters, example) and is appropriately sized. Most sentences earn their place by adding value, though the 'Returns' section could be more concise. It is front-loaded with the core purpose, making it easy to understand quickly.

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 the complexity (5 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, provides use cases, details parameters, and includes an example. However, it lacks information on output format, pagination behavior beyond parameters, and error scenarios, 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.

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 already documents all parameters thoroughly. The description lists parameters with brief explanations (e.g., 'user_id: Numeric user ID', 'username: Username string (use either user_id or username)'), but these add minimal value beyond what's in the schema. The example provides some usage context, but overall, the description does not significantly enhance parameter understanding beyond the schema's comprehensive coverage.

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 verbs ('Get all discussion threads started by a user') and resource ('discussion threads initiated by the specified user across issues, merge requests, and other collaborative contexts'). It distinguishes itself from sibling tools like gitlab_get_user_issue_comments or gitlab_get_user_mr_comments by focusing on threads started by the user rather than comments or other contributions.

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 context for when to use this tool ('Leadership and initiative tracking', 'Communication effectiveness analysis', etc.), but does not explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage through use cases but lacks explicit exclusions or comparisons to similar tools like gitlab_get_user_resolved_threads.

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