Action domain

server

Every action this domain exposes through gitlab_execute_action, from the gitlab://tools manifest. Each entry folds out to its full upstream description and required parameters.

2 · actions0 · destructive2 · read-only

Counted with a Free-tier token against gitlab.com, which is the only host this endpoint talks to: to use it against a self-managed instance, run the server yourself — its documentation covers that. The catalog is scoped to the token that asks, so the count moves with both its tier and its permissions: higher tiers expose more actions, and administration domains only appear to tokens allowed to use them. That is why the figures differ elsewhere: the upstream project counts 868 operations on Community Edition and up to 1,094 on GitLab.com's top tier, while this deployment publishes 768 because it is OAuth-only and acts with your token, so the administration domains a non-admin account cannot call never appear. All three describe the same catalog, counted from three vantage points.

Each entry also says what a GitLab fine-grained personal access token needs to run it, as GitLab 19.4.1 declares it: every permission of one line, at one of the boundaries named. Where there are alternatives, any one is enough.

Back to the server card

1. server.health_check

   Server Health Checkread-only

   Verify MCP server connectivity to GitLab, authenticated identity, and response health before troubleshooting other tool failures.

   Required parameters: No required parameters

   Fine-grained token: Metadata: Read at instance

2. server.status

   Server Statusread-only

   Check MCP server connectivity, GitLab reachability, and authenticated identity details. Returns: the server and GitLab health diagnostics, with the GitLab version, revision, edition and agent server, and the authenticated user. See also: user.me.

   Required parameters: No required parameters

   Fine-grained token: Metadata: Read at instance