Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

discover_tools

Read-only

List available GitLab tool categories or activate a specific one for the current session without loading every tool schema.

Instructions

List or activate a toolset for this session. Omit category to list; pass one to enable. Prefer this over GITLAB_TOOLSETS=all (loads ~all schemas). Session-only; with OAUTH_STATELESS_MODE=true persist GITLAB_TOOLSETS=core,<category> instead. Categories: core, merge_requests, issues, repositories, branches, projects, labels, ci, groups, pipelines, milestones, wiki, releases, tags, snippets, users, workitems, webhooks, search, variables, dependency_proxy, vulnerabilities, orbit. Response lists already-active ones. api is explicit-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "discover_tools"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryNoToolset to activate (e.g. pipelines, wiki). Omit to list. Prefer a category over GITLAB_TOOLSETS=all. Session-only; persist `GITLAB_TOOLSETS=core,<category>` when OAUTH_STATELESS_MODE=true.
jmespathNoOptional JMESPath expression filtering the JSON result before return.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.22
    • changedInput schema / properties / category / description
      Previous value: -"Toolset category to activate (e.g. 'pipelines', 'wiki'). Omit to list available categories."New value: +"Toolset to activate (e.g. pipelines, wiki). Omit to list. Prefer a category over GITLAB_TOOLSETS=all. Session-only; persist `GITLAB_TOOLSETS=core,<category>` when OAUTH_STATELESS_MODE=true."
  2. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  3. Addedv2.1.45
  4. Removedv2.1.43
  5. Addedv2.1.18
  6. Removedv2.1.14
  7. Addedv2.1.11
  8. Removedv2.1.10
  9. Addedv2.1.9

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the bar is lower, yet the description adds real context beyond them: activation is session-scoped and non-persistent, the stateless-mode workaround, and that the response lists already-active toolsets. The one gap is that 'activate a toolset' is a session-state change that sits in mild tension with readOnlyHint=true, and the description never reconciles that — no note that no remote data is modified.

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

Conciseness4/5

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

Front-loaded with the core action and the list/enable switch before any caveats, and no sentence is filler — even the long category enumeration is load-bearing since the schema has no enum. It is dense at roughly one paragraph plus a 24-item list, which is near the upper bound of comfortable scanning but justified by the missing enum.

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

Completeness5/5

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

With no output schema, the description compensates by describing the return ('Response lists already-active ones'), and it covers the persistence model, the stateless-mode alternative, the preferred alternative to all-schemas loading, and the full valid value set. For a two-parameter session tool, nothing an agent needs to call it correctly is missing.

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 baseline is 3. The description does add genuine value the schema lacks, enumerating all 24 valid category values where the schema only offers two examples ('e.g. pipelines, wiki'), but it adds nothing about the jmespath parameter beyond what the schema already states.

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 opens with a precise dual-purpose statement: 'List or activate a toolset for this session,' then immediately disambiguates the two modes ('Omit category to list; pass one to enable'). This is clearly distinct from every sibling tool, which performs GitLab domain operations, so an agent can identify this as a tool-discovery/toolset-management utility without opening the schema.

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?

It gives explicit conditional guidance for both arguments (omit vs pass a category) and names the alternative it should replace: 'Prefer this over GITLAB_TOOLSETS=all (loads ~all schemas).' It also supplies the correct substitute path for stateless deployments ('with OAUTH_STATELESS_MODE=true persist `GITLAB_TOOLSETS=core,<category>` instead') and flags 'api is explicit-only,' leaving little to infer.

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