cicd-aiops

list_merge_requests

Read-only

Retrieve merge or pull requests for a project, filter by state, and limit results to review open changes and track code review status.

Instructions

[READ] Merge/pull requests for a project (default: open ones).

Args: project: Project id or full path ('group/project' / 'owner/repo'). state: opened/open, merged, closed, all (platform word is translated). limit: Max rows to return (default 50, max 99); the result carries 'truncated' when the server had more. target: Server target name from config; omit for the default.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "list_merge_requests"
  }
}

Input Schema

Name	Required	Default
`limit`	No
`state`	No	opened
`target`	No
`project`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Jul 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

readOnlyHint already covers the safety profile, and the description adds real operational context beyond it: the limit cap (max 99), the 'truncated' flag that signals the server had more rows, and the note that platform-specific state words are translated. It does not describe the shape of returned rows, but the annotations carry the main burden.

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?

Front-loaded with a bracketed read marker and a one-line summary, then a tight per-argument list. Every sentence conveys distinct, necessary information with no filler.

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?

For a listing tool with no output schema, the description covers selection, filtering, result-size limits and truncation warning. The only gap is the absence of any hint about the fields each merge request carries, which is minor given the task is enumeration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all parameter meaning and it does: project accepts an id or full path with concrete examples, state lists the accepted values, limit documents default and max plus truncation, and target explains the config-derived server selector. This fully compensates for the empty schema.

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?

States a specific verb (list) and resource (merge/pull requests) scoped to a project, with the default filter (open ones) made explicit. An agent can distinguish it from list_pipelines, list_branches and other list_* siblings without opening the schema.

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

Usage Guidelines3/5

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

The default state and the enumeration of accepted state values imply when to use it (open MRs by default, widen with state), but there is no explicit when/when-not guidance or named alternative tool. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.