Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_issue_discussions

Read-only

Fetch threaded discussions for a GitLab issue using project ID and issue IID; supports pagination, summary fields, and JMESPath filtering for focused review.

Instructions

List discussions for an issue. List threaded discussions for an issue. Use list_issues or get_issue for issue records.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default 1)
summaryNoIf true, return only high-signal fields (id, iid, title, state, web_url, …). Default false keeps the full GitLab JSON.
jmespathNoOptional JMESPath expression filtering the JSON result before return.
per_pageNoItems 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. Changed2 schema fields changedv2.3.22
    • changedInput schema / properties / page / description
      Previous value: -"Page number for pagination (default: 1)"New value: +"Page number (default 1)"
    • changedInput schema / properties / per_page / description
      Previous value: -"Number of items per page (max: 100, default: 20)"New value: +"Items per page (max 100, default 20)"
  2. Changed1 schema field changedv2.3.8
    • addedInput schema / properties / summary
      Added value: +{
+  "description": "If true, return only high-signal fields (id, iid, title, state, web_url, …). Default false keeps the full GitLab JSON.",
+  "type": "boolean"
+}
  3. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  4. Addedv2.1.45
  5. Removedv2.1.43
  6. Addedv2.1.18
  7. Removedv2.1.14
  8. Addedv2.1.11
  9. Removedv2.1.10
  10. Changed2 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / required
      Added value: +[
+  "project_id",
+  "issue_iid"
+]
  11. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and reach are covered structurally. Beyond that the description adds almost nothing behavioral: it does not say the result is threaded notes, whether pagination is required to collect all discussions, or that empty results mean no discussion thread exists. The word "threaded" is the only behavioral signal, and it merely restates the resource name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are near-duplicates — "List discussions for an issue" and "List threaded discussions for an issue" — so one is pure waste in a three-sentence description. The routing sentence is well placed at the end, but the tapering redundancy drags down an otherwise short text.

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

Completeness3/5

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

This is a simple read-only list tool with fully documented parameters and no output schema, so much of the burden is off the description. Still, an agent gets no sense of what a discussion object contains (threaded notes) or how paging interacts with the result set, which are the two things that would round out a listing tool like this.

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% and all six parameters (including `page`, `per_page`, `summary`, and `jmespath`) are documented in the schema itself. The description adds no meaning beyond that, so the baseline of 3 applies.

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 names a specific verb and resource ("List threaded discussions for an issue") and explicitly routes issue-record needs to `list_issues`/`get_issue`, so it is distinguishable from the closest siblings. It does not distinguish itself from discussion-oriented siblings such as `mr_discussions` or `get_merge_request_discussion`, but resource scope (issue vs. merge request) is unambiguous.

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?

It provides one explicit exclusion — use `list_issues` or `get_issue` for issue records rather than this tool — which is useful negative guidance. It never states the positive trigger case (e.g., reading comment threads on an issue to review feedback) or mentions pagination-driven iteration, so the guidance is partial rather than complete.

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