list_labels doesn't expose label ID, blocking update_label workflow

[Hakihiro]

Summary

mcp__gitlab__list_labels returns label name, color, description and usage counts, but not the numeric id. However, mcp__gitlab__update_label requires label_id: number as a mandatory parameter, with no alternative.

Result: a complete "list → update" workflow is impossible through MCP alone — a glab or raw curl fallback is required to fetch label IDs.

Reproduction

1. Call mcp__gitlab__list_labels(group_id: "my-group", search: "Parent::")
2. Observe output — IDs are absent
3. Try to call mcp__gitlab__update_label(group_id: "my-group", label_id: ???, color: "#E74C3C") — no way to know the ID

Real-world context

I was applying a color palette to 28 Parent::XXX-## group labels on gitlab.org/my-group. Had to fall back to a bash loop with curl PUT /groups/:id/labels/:name_urlencoded to complete the task, defeating the purpose of using MCP.

Proposed fixes (by order of simplicity)

1. Minimal: expose id field in list_labels output (one line in the formatter).
2. Better: accept label_name as an alternative to label_id in update_label (and also in create_label for idempotency — currently create_label errors if the label exists, with no way to "upsert").
3. Ideal: add a verbose or output: "json" parameter on list_labels for structured output that callers can filter programmatically.

Impact on other tools

Worth auditing other MCP tools that take a numeric *_id but whose corresponding list_* doesn't expose it:

• delete_label (same shape if it exists)
• Any other update_* / delete_* that takes a numeric ID while list_* only returns names

Environment

• Server: @wanadev/mcp-gitlab v1.3.2
• Host: GitLab Premium 18.x self-hosted (gitlab.org)
• Client: Claude Code CLI

[Hakihiro]

Implemented — list_labels now exposes label IDs in output, and update_label/delete_label tools accept label_id.