Skip to main content
Glama
Sign In
ttpears

GitLab MCP Server

by ttpears
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Work Items

list_work_items
Read-onlyIdempotent

List and filter GitLab work items such as issues, tasks, epics, incidents, objectives, and key results by namespace, type, and state with cursor pagination.

Instructions

List work items within a namespace (group or project fullPath). Supports filtering by type (ISSUE, TASK, EPIC, INCIDENT, OBJECTIVE, KEY_RESULT) and state, plus cursor pagination and fetchAll.

Input Schema

NameRequiredDescriptionDefault
sortNoSort enum, e.g. UPDATED_DESC (default), CREATED_DESC, TITLE_ASC
afterNoCursor for next page
firstNoPage size (default 20, capped by server maxPageSize)
stateNoFilter by state. "all" returns every state.
typesNoFilter by work item types. Omit for all types.
fetchAllNoAuto-paginate up to first items
fullPathYesNamespace full path — group (e.g. "my-group") or project (e.g. "my-group/my-project")
userCredentialsNoYour GitLab credentials (optional — falls back to the configured env token if not provided)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / userCredentials / anyOf
      Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "accessToken": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "gitlabUrl": {
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "properties": {
+      "accessToken": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "gitlabUrl": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Addedv1.15.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the pagination model (cursor plus fetchAll) and the filter dimensions, which is useful context beyond annotations. However, it says nothing about ordering behavior, cross-subgroup scope for a group fullPath, or what the response contains despite there being no output schema.

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, front-loaded with the resource and its scope before the optional capabilities. Every clause maps to a real capability (filters, pagination) and there is no filler.

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?

With 8 parameters, no output schema, and no return-value documentation, the description should carry more weight than one line on filters and pagination. It never states whether a group fullPath includes descendant projects or what a page of results looks like. Annotations cover safety, but result-shape and scope semantics are left open.

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 every one of the 8 parameters is documented in the schema itself. The description restates the type and state filters but omits two valid enum members (TEST_CASE, REQUIREMENT) and adds no format or syntax detail for after/first/fetchAll. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a specific verb and resource (list work items) and pins the scope to a namespace fullPath, which implicitly separates it from get_work_item and the search_* tools. It enumerates the type and state filters, so an agent knows this is the namespace-scoped work item lister. It never names a sibling outright, so the differentiation is inferred rather than explicit.

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?

Usage is only implied: 'within a namespace' plus the supported filters tells an agent roughly when this fits, but there is no statement of when to prefer search_issues, get_issues, or get_work_item instead. No prerequisites or exclusions are mentioned. It is adequate but leaves routing decisions to inference.

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