Skip to main content
Glama
zereight

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_issue_discussions

Read-only

Retrieve threaded discussions for a specific GitLab issue by providing the project ID and issue IID. Filter results with optional pagination and JMESPath, with errors for invalid IDs or permissions.

Instructions

List discussions for an issue. Use this to inspect threaded discussions for an issue; use list_issues for issue records and get_issue for one issue's fields. It is read-only and returns discussion items, while invalid identifiers, missing issues, and permission failures are reported as errors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
jmespathNoOptional JMESPath expression filtering the JSON result before return.
per_pageNoNumber of items per page (max: 100, default: 20)
issue_iidYesThe internal ID of the project issue
project_idYesProject ID or URL-encoded path

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  2. Addedv2.1.45
  3. Removedv2.1.43
  4. Addedv2.1.18
  5. Removedv2.1.14
  6. Addedv2.1.11
  7. Removedv2.1.10
  8. Changed2 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / required
      Added value: +[
+  "project_id",
+  "issue_iid"
+]
  9. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

The description states it is read-only (matching readOnlyHint=true) and adds error behavior: invalid identifiers, missing issues, and permission failures are reported as errors. It also says it returns discussion items. While annotations already cover the read-only safety profile, the error reporting adds value beyond annotations. It doesn't contradict annotations.

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?

Two sentences with no filler. The core purpose is front-loaded, and the sibling differentiation and error behavior are compactly included. Every word earns its place.

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?

The description covers purpose, usage, and error behavior, and the schema covers parameters and pagination. It does not describe the exact structure of returned discussion items, but for a list tool with no output schema, this is a minor gap. The tool is adequately specified for correct invocation.

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 all five parameters are already fully documented in the schema. The description adds no extra parameter-level detail, but given the complete schema, the baseline of 3 is appropriate.

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 action (list discussions) and the target (an issue), and explicitly differentiates it from `list_issues` and `get_issue`, so an agent can immediately tell what this tool does and how it differs from close siblings.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: use this to inspect threaded discussions, use `list_issues` for issue records, and `get_issue` for single issue fields. This provides both when-to-use and when-not-to-use with named alternatives.

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

Deploy Server

Other Tools