MCP Capabilities
GitLab MCP Server implements 4 MCP protocol capabilities — progress, elicitation, completions, and resource subscriptions — that go beyond basic tool calling to make AI assistants more accurate and interactive when working with GitLab. It also attaches icon metadata to every tool, resource, and prompt. Together these features let assistants report progress, ask the user for input through structured forms, autocomplete argument values, watch GitLab resources for change, and present recognizable per-domain icons.
The 4 capabilities are negotiated during the MCP initialization handshake, while icons are presentation metadata that clients render or ignore. None of them is required for core tool calls to work: when a client lacks support, the server degrades gracefully and the underlying GitLab operation still completes.
What capabilities does GitLab MCP Server provide?
Section titled “What capabilities does GitLab MCP Server provide?”GitLab MCP Server provides five distinct features, summarized below. Progress and elicitation push information from the server to the client, completions pull suggestions from the server on demand, subscriptions notify the client when a watched resource changes, and icons are static metadata attached to every surface.
| Capability | Direction | What It Enables |
|---|---|---|
| Progress | Server → Client | Real-time progress updates for long-running operations |
| Elicitation | Server → Client | Interactive wizards — step-by-step forms for creating complex resources |
| Completions | Client → Server | Argument autocompletion for project names, branches, users, and more |
| Subscriptions | Client → Server (updates Server → Client) | Live change notifications for 26 GitLab resource kinds, honored by polling (GITLAB_MCP_CAPABILITY_SURFACE=full only) |
| Icons (metadata) | Server → Client | Icons for every tool, resource, and prompt — SVG plus light/dark WebP fallbacks |
How are MCP capabilities negotiated?
Section titled “How are MCP capabilities negotiated?”Capabilities are negotiated once, during the MCP initialization handshake between the client and server. Each side advertises what it supports, so neither attempts to use a feature the other cannot handle. After the handshake, the server can send progress notifications and elicitation requests, and the client can request completions.
Server-declared capabilities (completions) are always available because GitLab MCP Server advertises them unconditionally. Client-dependent capabilities (elicitation) require the MCP client to declare support — the server checks for it before using the capability and gracefully degrades when it is unavailable, falling back to standard parameterized tools so no functionality is lost.
Which MCP clients support each capability?
Section titled “Which MCP clients support each capability?”Capability support varies by MCP client, and GitLab MCP Server adapts automatically to whatever the connected client advertises. The table below reflects common clients at the time of writing; because client support evolves quickly, confirm the current state against each client’s own documentation.
| Capability | Claude Desktop | VS Code Copilot | Cursor | Claude Code |
|---|---|---|---|---|
| Progress | ✅ | ✅ | ✅ | ✅ |
| Completions | ✅ | ✅ | ❓ | ✅ |
| Elicitation | ✅ | ❌ | ❌ | ✅ |
| Subscriptions² | ❓ | ✅ | ❓ | ❓ |
| Icons¹ | ❌ | ✅ | ❓ | ❌ |
² VS Code subscribes automatically to every resource it reads and routes
resources/updated into its file-change pipeline. Cursor sends
resources/subscribe requests (even to servers that do not advertise the
capability), but whether it surfaces the resulting notifications is
unverified — as is subscription handling in Claude Desktop and Claude Code.
Clients that never subscribe lose nothing: resources remain readable on
demand.
¹ Icons are not a negotiated capability: the server always attaches them and a
client that cannot render any of them simply ignores them, losing nothing
functional. The column records whether a client renders at least one of the
three entries gitlab-mcp-server attaches to every icon — a scalable SVG plus
light/dark WebP fallbacks — not whether it supports every format. VS Code
Copilot, for example, rejects the SVG entry (image/svg+xml is not in its
MIME allowlist) but renders the theme-matched WebP fallback instead. See
Icons for the full client matrix.
Frequently asked questions
What is the difference between server-declared and client-dependent capabilities?
Server-declared capabilities, such as completions, are advertised unconditionally by GitLab MCP Server and available to any client that calls them. Client-dependent capabilities, such as elicitation, require the MCP client to declare support during initialization. The server checks for that support before using the capability and degrades gracefully when it is missing — for elicitation, it falls back to standard parameterized tools, so functionality is preserved and only the interactive experience is reduced.
What MCP capabilities does GitLab MCP Server implement?
GitLab MCP Server implements four MCP protocol capabilities — progress, elicitation, completions, and resource subscriptions — plus icon metadata on every tool, resource, and prompt. Progress sends real-time updates during long-running operations, elicitation lets the server ask the user for input through structured forms, completions autocomplete argument values such as project names, branches, users, and labels, and resource subscriptions deliver live change notifications for 26 GitLab resource kinds, honored by polling. Icons are presentation metadata, not a negotiated protocol capability. The four capabilities are negotiated during the MCP initialization handshake.
What happens if my MCP client does not support a capability?
GitLab MCP Server adapts automatically. Progress notifications are best-effort and silently ignored when unsupported, so tools still complete. Elicitation falls back to standard parameterized tools where the assistant supplies all parameters in one call. Completions are simply not offered, and values remain discoverable through the domain's list action (project.list, branch.list and so on through gitlab_execute_action on the default surface, or the list action of the matching meta-tool with GITLAB_MCP_TOOL_SURFACE=meta). Icons are optional metadata that non-rendering clients ignore. No capability is required for core tool functionality.
Which MCP clients support elicitation?
Elicitation is supported by Claude Desktop and Claude Code. VS Code Copilot and Cursor do not yet support it, so on those clients GitLab MCP Server falls back to standard parameterized creation tools. Because client capability support changes frequently, confirm the current state against the specific client's documentation.