Go MCP server for GitLab: 2 dynamic tools reach 1000+ REST/GraphQL actions. Free/CE, no paid tier.
Scored across 2 tools
The two tools have strictly separate roles: gitlab_find_action is read-only catalog search, while gitlab_execute_action is the sole execution path. Their descriptions explicitly guide when to use find first, leaving no realistic ambiguity.
Both follow the same gitlab_<verb>_action convention in snake_case with consistent, predictable verb placement. The naming is uniform and easy to infer.
Only two tools expose an enormous GitLab API surface. The catalog-multiplexer design is legitimate and each tool earns its place, but the surface is thin enough that agents must discover actions before they can act, which is at the low end of the rubric.
Because gitlab_execute_action is generic and catalog-backed, coverage is potentially complete for GitLab operations, including destructive ones via confirmation. However, there is no explicit browse-all or list operation, and actual breadth depends on the unseen catalog.
Execute one GitLab catalog action by canonical ID or alias. Always pass params as an object. Destructive actions require top-level confirm=true. Use find first only when action or params are unclear. Example: {"action":"issue.list","params":{"project_id":"group/project"}}
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close. | |
| params | Yes | Required action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters. | |
| confirm | No | Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action. |
| Name | Required | Description |
|---|---|---|
| next_steps | No | Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result. |
| pagination | No | Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`, or on a keyset page with `page_token` set to `next_page_token`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive, open-world, non-idempotent behavior. The description adds important operational context: destructive actions require top-level confirm=true, confirm must not go inside params, and params must always be an object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core operation, and includes a compact example. Every sentence carries routing, parameter, or safety information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex action dispatcher, it covers the essential execution vs discovery flow and destructive-action confirmation. With full schema coverage and an output schema, remaining details such as action-specific parameter shape are appropriately delegated to the selected action schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines action, params, and confirm. The description adds an example and reinforces that params is an object, but it does not add much beyond the structured parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: execute one GitLab catalog action by canonical ID or alias. It also distinguishes the tool from its sibling by explaining when to use gitlab_find_action first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance: execute when the action/params are known, and use find first only when they are unclear. It also states the confirm requirement for destructive actions, leaving little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the local GitLab action catalog. Read-only and no GitLab API call. Use when the action ID or params are unclear. Returns schemas, hints, destructive flags, and execute examples. Example: {"query":"issue list"}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches to return. Defaults to 20 and is capped at 50. | |
| query | Yes | Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. At most 256 characters: a longer query is refused, not truncated. | |
| explain | No | When true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of returned matches. |
| query | Yes | Original search query. |
| results | Yes | Matching GitLab catalog actions with schemas and execute examples. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and non-destructive, and the description adds genuinely new context: the catalog is local with no GitLab API call, so there is no auth or rate-limit exposure. It also previews what comes back (schemas, hints, destructive flags, execute examples), which annotations alone would not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences plus one inline example, with the local/read-only guarantee and the usage trigger front-loaded. Nothing repeats the schema or wastes a clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still briefly names the shape of the response, and it covers cost (no API call) and the routing decision. For a 3-parameter search tool this is everything an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (limit, query, explain) is documented in the schema, including caps and the no-truncation rule, so the schema carries the load. The description adds only an example query string and does not explain limit or explain beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search the local GitLab action catalog") and makes the search-vs-execute split legible through "Use when the action ID or params are unclear." It never names gitlab_execute_action, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger condition: use it when the action ID or params are unclear, which implicitly excludes the case where they are known. It does not explicitly point to the sibling execution tool as the alternative for that excluded case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
gitlab_find_action2 fields changedOutput schema / properties / results / items / properties / required_params_any_of / descriptionPrevious value: -"Alternative groups: a call also needs every name of one group, not all groups."New value: +"Alternative groups: a call also needs every name of at least one group, not all groups, and of exactly one when required_params_exclusive is true."Output schema / properties / results / items / properties / required_params_exclusiveAdded value: +{
+ "description": "True when a call completes exactly one group of required_params_any_of: GitLab refuses a call completing two as it refuses one completing none.",
+ "type": "boolean"
+}gitlab_execute_action6 fields changedOutput schema / properties / pagination / descriptionPrevious value: -"Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`."New value: +"Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`, or on a keyset page with `page_token` set to `next_page_token`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`."Output schema / properties / pagination / properties / has_more / descriptionPrevious value: -"True when more pages are available after the current one."New value: +"True when GitLab named a next page: `next_page` on an offset page, `next_page_token` on a keyset page. A keyset link can lead to one empty page after the last rows."Output schema / properties / pagination / properties / next_page / descriptionPrevious value: -"Next page index when `has_more` is true."New value: +"Next page index on an offset page that has a successor. It is 0 on the last page and on every keyset page, whose successor is `next_page_token`."Output schema / properties / pagination / properties / next_page_tokenAdded value: +{
+ "description": "On a page GitLab served by keyset pagination, which names no next_page, the value to pass back unchanged as `page_token` for the next page. Absent otherwise.",
+ "type": "string"
+}Output schema / properties / pagination / properties / total_items / descriptionPrevious value: -"Items across all pages, 0 when GitLab sends no total. On search, a lower bound inferred from this page."New value: +"Items across all pages, 0 when GitLab sends no total."Output schema / properties / pagination / properties / total_pages / descriptionPrevious value: -"Pages in all, 0 when GitLab sends no total. On search, a lower bound inferred from this page."New value: +"Pages in all, 0 when GitLab sends no total."gitlab_find_action1 field changedOutput schema / properties / results / items / properties / required_params_any_ofAdded value: +{
+ "description": "Alternative groups: a call also needs every name of one group, not all groups.",
+ "items": {
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}gitlab_execute_action4 fields changedOutput schema / properties / pagination / descriptionPrevious value: -"Present on list actions. Use `has_more` and `next_page` to paginate through results."New value: +"Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`."Output schema / properties / pagination / properties / totalRemoved value: -{
- "description": "Total item count when known (some endpoints omit it for performance).",
- "type": "integer"
-}Output schema / properties / pagination / properties / total_itemsAdded value: +{
+ "description": "Items across all pages, 0 when GitLab sends no total. On search, a lower bound inferred from this page.",
+ "type": "integer"
+}Output schema / properties / pagination / properties / total_pages / descriptionPrevious value: -"Total page count when known."New value: +"Pages in all, 0 when GitLab sends no total. On search, a lower bound inferred from this page."gitlab_find_action2 fields changedInput schema / properties / query / descriptionPrevious value: -"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable."New value: +"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. At most 256 characters: a longer query is refused, not truncated."Input schema / properties / query / maxLengthAdded value: +256gitlab_execute_actiongitlab_find_actionGitLab MCP — wraps the GitLab REST API v4 (BYO API key)
GitLab Public MCP — wraps the GitLab REST API v4 (public endpoints, no auth)
Free MCP server of security & dev API tools -- supply-chain, CVE, DNS, WHOIS, OFAC, Cosmos SDK.
A MCP server built for developers enabling Git based project management with project and personal…
Add one secure layer between your agents and this server.
