Skip to main content
Glama

CI Variable

gitlab_ci_variable
Destructive

Manage GitLab CI/CD variables across project, group, and instance scopes. Create, update, list, get, and delete variables with environment scoping support for per-env values.

Instructions

Example: {"action":"create","params":{...}} For the params schema of any action, read the MCP resource gitlab://schema/meta/gitlab_ci_variable/.

Manage GitLab CI/CD variables at instance, group, and project scope. Delete actions are irreversible. When to use: define / rotate / unmask / scope CI/CD variables at project, group, or instance level, both regular and secret (masked / masked_and_hidden), with environment scoping for per-env values. NOT for: linting CI YAML or browsing CI templates (use gitlab_template), pipeline runs or schedules (use gitlab_pipeline), feature flags (use gitlab_feature_flags), per-deployment env metadata (use gitlab_environment), GitLab instance settings (use gitlab_admin).

Returns:

  • list / group_list / instance_list: arrays of variable objects {key, value (or hidden), variable_type, protected, masked, raw, environment_scope, description} with pagination.

  • get / create / update / group_get / group_create / group_update / instance_get / instance_create / instance_update: single variable object.

  • delete / group_delete / instance_delete: {success, message}. Errors: 404 (hint: a (key, environment_scope) pair must exist for get/update/delete — supply environment_scope when the variable is env-scoped), 403 (hint: project requires Maintainer+, group requires Owner, instance requires admin), 400 (hint: variable_type ∈ env_var/file; masked requires single-line non-empty value matching GitLab's masking rules).

Param conventions: * = required. Project-scoped actions need project_id*, group-scoped need group_id*, instance-scoped need no ID. Common optional params: variable_type, protected, masked, raw, environment_scope.

Project variables:

  • list: project_id*

  • get / delete: project_id*, key*, environment_scope

  • create: project_id*, key*, value*, description, variable_type, protected, masked, masked_and_hidden, raw, environment_scope

  • update: project_id*, key*, value, description, variable_type, protected, masked, raw, environment_scope

Group variables (group_*):

  • group_list: group_id*

  • group_get / group_delete: group_id*, key*

  • group_create: group_id*, key*, value*, description, variable_type, protected, masked, raw, environment_scope

  • group_update: group_id*, key*, value, description, variable_type, protected, masked, raw, environment_scope

Instance variables (instance_*):

  • instance_list: (no params)

  • instance_get / instance_delete: key*

  • instance_create: key*, value*, description, variable_type, protected, masked, raw

  • instance_update: key*, value, description, variable_type, protected, masked, raw

See also: gitlab_pipeline (pipeline operations), gitlab_template (CI lint)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform. Pick exactly one of the values in `enum`. Each action expects its own `params` object — see the tool description for the per-action parameter list.
paramsNoAction-specific parameters as a JSON object. Required and optional fields differ per action; consult this tool's description for the chosen action. Send only the fields documented for that action — unknown keys are rejected with a validation error (only reserved meta keys like `confirm` are stripped before validation). For the JSON Schema of a specific action's `params`, read the MCP resource `gitlab://schema/meta/{tool}/{action}` (replace placeholders with the tool name and the chosen action).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.
Behavior5/5

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

Disclosure of irreversibility for delete actions aligns with destructiveHint annotation. Details auth requirements (Maintainer+ for project, Owner for group, admin for instance), error codes (404, 403, 400), and return structures. No contradiction with annotations.

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?

The description is well-structured with clear sections (example, purpose, usage, returns, errors, params) and front-loaded with essential info. However, it is lengthy and contains some redundancy between the param conventions and per-action lists, which could be streamlined.

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?

Covers all aspects needed: purpose, usage, behavior, params, errors, return values, and references to external schema. For a tool with 18 actions across 3 scopes, the description is remarkably complete and leaves no obvious gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds substantial value by providing per-action parameter lists, required vs optional fields, and examples. It clarifies the params object structure and links to a resource for complete schema per action.

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 clearly states the tool manages GitLab CI/CD variables at instance, group, and project scope. It lists specific actions and distinguishes from siblings by explicitly stating what the tool is NOT for and naming alternatives like gitlab_pipeline, gitlab_template, etc.

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?

Provides explicit when-to-use scenarios (define/rotate/unmask/scope variables) and when-not-to-use with sibling tool names. Also gives per-action parameter requirements and error hints, guiding the AI on correct usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmrplens/gitlab-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server