Skip to main content
Glama

Job

gitlab_job
Destructive

Manage GitLab CI/CD jobs by retrying, canceling, playing manual jobs, retrieving logs and artifacts, and configuring job token scope and trust boundaries.

Instructions

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

Manage GitLab CI/CD jobs and the CI/CD job token scope: lifecycle, manual play, log/artifact retrieval, and inbound trust boundaries. Erase/delete actions are destructive. When to use: job details, logs, artifacts, retry/cancel jobs, job token scope. NOT for: pipeline-level operations (use gitlab_pipeline).

Behavior:

  • Idempotent reads: list / list_project / get / trace / artifacts / download_artifacts / download_single_artifact / download_single_artifact_by_ref / list_bridges / token_scope_get / token_scope_list_inbound / token_scope_list_groups.

  • retry starts a NEW job run on every call (NON-idempotent — returns a fresh job_id). play activates an existing manual job that has not yet run (same job_id; only manual jobs with rules.when=manual are eligible) and may pass new variables. cancel is idempotent (no-op once final). keep_artifacts / token_scope_patch / token_scope_add_project / token_scope_add_group are idempotent.

  • Side effects: retry / play queue runners, consume CI minutes, and may trigger downstream pipelines and notifications. trace returns up to 100KB of log; download_artifacts streams up to 1MB inline (base64).

  • Destructive: erase clears the job log and artifacts in place (irreversible); delete_artifacts removes a single job's artifacts; delete_project_artifacts wipes ALL artifacts across the project (irreversible). token_scope_remove_* tightens trust boundaries and may break running pipelines.

Param conventions: * = required. All job actions need project_id*. List actions accept page, per_page.

Jobs:

  • list: project_id*, pipeline_id*, scope

  • list_project: project_id*, scope, include_retried

  • get: project_id*, job_id*

  • trace: project_id*, job_id*. Returns job log (truncated to 100KB).

  • cancel / retry / erase / keep_artifacts: project_id*, job_id*

  • play: project_id*, job_id*, variables (array of {key, value, variable_type})

  • wait: project_id*, job_id*, interval_seconds (5-60, default 10), timeout_seconds (1-3600, default 300), fail_on_error (default true)

  • list_bridges: project_id*, pipeline_id*, scope

  • delete_artifacts: project_id*, job_id*

  • delete_project_artifacts: project_id*. Deletes ALL artifacts across project.

Artifact downloads (base64, max 1MB):

  • artifacts: project_id*, job_id*

  • download_artifacts: project_id*, ref_name*, job

  • download_single_artifact: project_id*, job_id*, artifact_path*

  • download_single_artifact_by_ref: project_id*, ref_name*, artifact_path*, job

Job token scope:

  • token_scope_get / token_scope_patch: project_id*. Patch params: enabled.

  • token_scope_list_inbound: project_id*

  • token_scope_add_project / token_scope_remove_project: project_id*, target_project_id*

  • token_scope_list_groups: project_id*

  • token_scope_add_group / token_scope_remove_group: project_id*, target_group_id*

See also: gitlab_pipeline, gitlab_repository

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?

Beyond annotations (destructiveHint, openWorldHint), the description details idempotent vs non-idempotent actions, side effects (retry/play consume CI minutes, trigger pipelines), destructive irreversible actions (erase, delete_project_artifacts), and limits (trace 100KB, download 1MB). 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?

Well-structured with clear sections (Behavior, Param conventions, Jobs, Artifact downloads, Job token scope) and a front-loaded example. However, it is lengthy due to enumerating all actions; while justified by complexity, slight conciseness could be improved.

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: actions, idempotency, side effects, destructive operations, per-action parameters, limits, and references to external schema for full details. For a tool with 25+ actions, this is comprehensive and leaves no significant 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?

Schema coverage is 100%, but the description adds extensive per-action parameter lists, conventions (required fields marked with *), and special behaviors (e.g., play expects variables array). It significantly enriches the schema information, making it highly actionable.

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 is for managing GitLab CI/CD jobs and job token scope, listing many specific actions (lifecycle, log/artifact retrieval, trust boundaries). It distinguishes from sibling tools like gitlab_pipeline by explicitly noting 'NOT for: pipeline-level operations (use gitlab_pipeline)'.

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?

Explicitly states when to use ('job details, logs, artifacts, retry/cancel jobs, job token scope') and when not to ('pipeline-level operations (use gitlab_pipeline)'). Also includes 'See also' referencing related tools, providing clear guidance for the agent.

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