Skip to main content
Glama

gitlab_get_user_open_issues

Retrieve and manage open issues assigned to or created by a specific GitLab user. Filter by severity, SLA status, or sort by priority to track workload and compliance.

Instructions

List open issues assigned to or created by a specific user.

Use this tool to see what issues a user is currently working on or responsible for.

Retrieve all currently open issues assigned to the specified user across all accessible projects, with intelligent priority sorting.

Returns prioritized issue list with:

  • Issue details: title, description, labels

  • Priority indicators: severity, SLA status

  • Context: project, milestone, due date

  • Activity: recent updates, comment count

  • Assignment: other assignees, collaboration info

Use cases:

  • Personal issue dashboard and inbox

  • Workload management and planning

  • SLA compliance tracking

  • Sprint and milestone planning

Parameters:

  • user_id: Numeric user ID

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

  • severity: Filter by severity level

  • sla_status: Filter by SLA compliance (at_risk, overdue, ok)

  • sort: Sort order (priority, due_date, updated)

  • per_page: Results per page (default: 20)

  • page: Page number (default: 1)

Example: Get overdue issues for user

{
  "username": "johndoe",
  "sla_status": "overdue",
  "sort": "priority"
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idNoNumeric user ID
usernameNoUsername string
severityNoFilter by severity level
sla_statusNoFilter by SLA compliance
sortNoSort orderpriority
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 main handler function that implements the tool logic, extracting parameters and calling the GitLabClient's get_user_open_issues method.
    def handle_get_user_open_issues(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Dict[str, Any]:
        """Handle getting user's open issues"""
        user_id = get_argument(arguments, "user_id")
        username = get_argument(arguments, "username")
        severity = get_argument(arguments, "severity")
        sla_status = get_argument(arguments, "sla_status")
        sort = get_argument(arguments, "sort", "priority")
        per_page = get_argument(arguments, "per_page", DEFAULT_PAGE_SIZE)
        page = get_argument(arguments, "page", 1)
        
        return client.get_user_open_issues(
            user_id=user_id,
            username=username,
            severity=severity,
            sla_status=sla_status,
            sort=sort,
            per_page=per_page,
            page=page
        )
  • The MCP tool definition including input schema and description.
    types.Tool(
        name=TOOL_GET_USER_OPEN_ISSUES,
        description=desc.DESC_GET_USER_OPEN_ISSUES,
        inputSchema={
            "type": "object",
            "properties": {
                "username": {"type": "string", "description": "Username string"},
                "scope": {"type": "string", "description": "Issue scope", "enum": ["created", "assigned", "all"], "default": "all"},
                "labels": {"type": "string", "description": "Comma-separated label names"},
                "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 tool name to its handler function in the TOOL_HANDLERS dictionary.
    TOOL_GET_USER_OPEN_ISSUES: handle_get_user_open_issues,
  • Constant defining the tool name string.
    TOOL_GET_USER_OPEN_ISSUES = "gitlab_get_user_open_issues"
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 key behaviors: the tool retrieves issues 'across all accessible projects' (scope), uses 'intelligent priority sorting' (sorting logic), returns a 'prioritized issue list' with detailed fields (output structure), and supports pagination via per_page and page parameters. It also mentions filtering capabilities and default values. While it doesn't cover rate limits or authentication needs, it provides substantial behavioral context beyond basic functionality.

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, usage, returns, use cases, parameters, example) and front-loads the core functionality. However, it includes some redundancy (e.g., listing parameters that are fully documented in the schema) and the 'Use cases' section, while helpful, adds length without critical new information. Most sentences earn their place, but minor trimming could improve 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 the tool's moderate complexity (7 parameters, no output schema, no annotations), the description provides strong contextual completeness. It covers purpose, usage, behavioral traits, output structure, use cases, and parameters with an example. The main gap is the lack of an output schema, but the description compensates by detailing the return format ('Returns prioritized issue list with...'). It could be more explicit about error handling or permissions, but overall it's highly informative.

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 adds minimal value beyond the schema: it clarifies that either user_id or username can be used ('use either user_id or username'), provides an example usage, and lists parameters with brief notes. However, it doesn't explain parameter interactions or add significant semantic context that isn't already in the schema descriptions, meeting the baseline for high schema 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 specific action ('List open issues assigned to or created by a specific user') and resource ('issues'), distinguishing it from sibling tools like gitlab_get_issue (single issue) or gitlab_list_issues (general listing). It explicitly mentions the scope ('across all accessible projects') and purpose ('see what issues a user is currently working on or responsible for'), providing excellent differentiation.

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 ('Use this tool to see what issues a user is currently working on or responsible for') and lists specific use cases (personal dashboard, workload management, SLA tracking, sprint planning). However, it doesn't explicitly state when NOT to use it or name alternative tools for similar purposes, such as gitlab_get_user_reported_issues or gitlab_get_user_resolved_issues, which could help avoid confusion.

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