Skip to main content
Glama
Sign In

GitLab MCP Server

by io.github.jmrplens
OverviewDiscussionsAdmin

GitLab Execute Action

gitlab_execute_action
Destructive

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"}}

Input Schema

NameRequiredDescriptionDefault
actionYesCanonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close.
paramsYesRequired action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters.
confirmNoSet top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action.

Output Schema

NameRequiredDescriptionDefault
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent 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`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedOutput schema / properties / pagination / description
      Previous 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`."
    • changedOutput schema / properties / pagination / properties / has_more / description
      Previous 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."
    • changedOutput schema / properties / pagination / properties / next_page / description
      Previous 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`."
    • addedOutput schema / properties / pagination / properties / next_page_token
      Added 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"
+}
    • changedOutput schema / properties / pagination / properties / total_items / description
      Previous 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."
    • changedOutput schema / properties / pagination / properties / total_pages / description
      Previous 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."
  2. Changed4 schema fields changed
    • changedOutput schema / properties / pagination / description
      Previous 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`."
    • removedOutput schema / properties / pagination / properties / total
      Removed value: -{
-  "description": "Total item count when known (some endpoints omit it for performance).",
-  "type": "integer"
-}
    • addedOutput schema / properties / pagination / properties / total_items
      Added value: +{
+  "description": "Items across all pages, 0 when GitLab sends no total. On search, a lower bound inferred from this page.",
+  "type": "integer"
+}
    • changedOutput schema / properties / pagination / properties / total_pages / description
      Previous 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."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All GitLab MCP Server toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources