Skip to main content
Glama

list_merge_requests

Retrieve and filter merge requests in a GitLab project using criteria like assignee, state, labels, or date ranges to manage code review workflows.

Instructions

List merge requests in a GitLab project with filtering options

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoProject ID or URL-encoded path
assignee_idNoReturn issues assigned to the given user ID. user id or none or any
assignee_usernameNoReturns merge requests assigned to the given username
author_idNoReturns merge requests created by the given user ID
author_usernameNoReturns merge requests created by the given username
reviewer_idNoReturns merge requests which have the user as a reviewer. user id or none or any
reviewer_usernameNoReturns merge requests which have the user as a reviewer
created_afterNoReturn merge requests created after the given time
created_beforeNoReturn merge requests created before the given time
updated_afterNoReturn merge requests updated after the given time
updated_beforeNoReturn merge requests updated before the given time
labelsNoArray of label names
milestoneNoMilestone title
scopeNoReturn merge requests from a specific scope
searchNoSearch for specific terms
stateNoReturn merge requests with a specific state
order_byNoReturn merge requests ordered by the given field
sortNoReturn merge requests sorted in ascending or descending order
target_branchNoReturn merge requests targeting a specific branch
source_branchNoReturn merge requests from a specific source branch
wipNoFilter merge requests against their wip status
with_labels_detailsNoReturn more details for each label
pageNoPage number for pagination (default: 1)
per_pageNoNumber of items per page (max: 100, default: 20)

Implementation Reference

  • Zod input schema for 'list_merge_requests' tool defining parameters for listing GitLab merge requests including project_id, pagination, state, labels, scope, search, and other filters.
    export const ListMergeRequestsSchema = z
      .object({
        project_id: z.coerce.string().describe("Project ID or URL-encoded path"),
        assignee_id: z.coerce
          .string()
          .optional()
          .describe("Return issues assigned to the given user ID. user id or none or any"),
        assignee_username: z
          .string()
          .optional()
          .describe("Returns merge requests assigned to the given username"),
        author_id: z.coerce
          .string()
          .optional()
          .describe("Returns merge requests created by the given user ID"),
        author_username: z
          .string()
          .optional()
          .describe("Returns merge requests created by the given username"),
        reviewer_id: z.coerce
          .string()
          .optional()
          .describe("Returns merge requests which have the user as a reviewer. user id or none or any"),
        reviewer_username: z
          .string()
          .optional()
          .describe("Returns merge requests which have the user as a reviewer"),
        created_after: z
          .string()
          .optional()
          .describe("Return merge requests created after the given time"),
        created_before: z
          .string()
          .optional()
          .describe("Return merge requests created before the given time"),
        updated_after: z
          .string()
          .optional()
          .describe("Return merge requests updated after the given time"),
        updated_before: z
          .string()
          .optional()
          .describe("Return merge requests updated before the given time"),
        labels: z.array(z.string()).optional().describe("Array of label names"),
        milestone: z.string().optional().describe("Milestone title"),
        scope: z
          .enum(["created_by_me", "assigned_to_me", "all"])
          .optional()
          .describe("Return merge requests from a specific scope"),
        search: z.string().optional().describe("Search for specific terms"),
        state: z
          .enum(["opened", "closed", "locked", "merged", "all"])
          .optional()
          .describe("Return merge requests with a specific state"),
        order_by: z
          .enum([
            "created_at",
            "updated_at",
            "priority",
            "label_priority",
            "milestone_due",
            "popularity",
          ])
          .optional()
          .describe("Return merge requests ordered by the given field"),
        sort: z
          .enum(["asc", "desc"])
          .optional()
          .describe("Return merge requests sorted in ascending or descending order"),
        target_branch: z
          .string()
          .optional()
          .describe("Return merge requests targeting a specific branch"),
        source_branch: z
          .string()
          .optional()
          .describe("Return merge requests from a specific source branch"),
        wip: z
          .enum(["yes", "no"])
          .optional()
          .describe("Filter merge requests against their wip status"),
        with_labels_details: z.boolean().optional().describe("Return more details for each label"),
      })
      .merge(PaginationOptionsSchema);
Behavior2/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 states it's a list operation with filtering, but doesn't disclose critical behavioral traits such as pagination behavior (implied by 'page' and 'per_page' parameters but not described), rate limits, authentication requirements, or what the return format looks like (e.g., array of MR objects). This leaves significant gaps for an agent.

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 a single, efficient sentence that front-loads the core purpose ('List merge requests in a GitLab project') and adds a key feature ('with filtering options'). There's no wasted text, making it appropriately sized for its function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (24 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return values, pagination behavior, or error handling, leaving the agent with incomplete context to use the tool effectively. The schema covers parameters well, but behavioral aspects are missing.

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 fully documents all 24 parameters with descriptions and enums. The description adds no additional parameter semantics beyond stating 'with filtering options', which is already implied by the schema. Baseline 3 is appropriate as the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('merge requests in a GitLab project'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_issues' or 'get_merge_request', which would require mentioning it's for multiple merge requests with filtering capabilities.

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

Usage Guidelines2/5

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

The description mentions 'with filtering options', which implies usage for filtered queries, but provides no explicit guidance on when to use this tool versus alternatives like 'get_merge_request' (for a single MR) or 'list_issues' (for a different resource type). No prerequisites or exclusions are stated.

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/zereight/gitlab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server