gitlab-ci-mcp

Overview Schema Source Related Servers Discussions Admin

gitlab_get_job_log

Read-onlyIdempotent

Fetch GitLab CI job logs as a recent tail or regex-filtered lines with context to diagnose failures and locate errors in large logs without loading the full trace.

Instructions

Fetch the trace/log of a job, with optional regex filter.

Two modes:

Default: return the last tail lines (token-efficient, good for "why did this just fail?").
With grep_pattern: return only matching lines with grep_context surrounding lines on each side — ideal for finding "ERROR" / "Traceback" in megabyte-scale CI logs without pulling the whole trace into context.

Examples: - "Why did job 789 fail" → default tail=100, look at the end of the log - "Show me the first stage output of job 789" → tail=5000 and scan for stage separator - "Find every Traceback in job 789" → grep_pattern='Traceback', grep_context=5 - "All ERROR lines from job 789" → grep_pattern='ERROR|FAIL'

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>",
      "project_path": "<project_path>"
    },
    "name": "gitlab_get_job_log"
  }
}

Input Schema

Name	Required	Description
`tail`	No	Return only the last N lines (1–5000, default 100).
`job_id`	Yes	Numeric job ID (from ``gitlab_get_pipeline_jobs``).
`grep_context`	No	Surrounding lines to include around each grep match (0–20).
`grep_pattern`	No	Optional regex — when set, returns only lines matching the pattern (with ``grep_context`` surrounding lines) instead of the tail. Great for finding errors in huge logs without downloading everything. Invalid regex falls back to literal substring match.
`project_path`	Yes	GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted.

Output Schema

Name	Required	Description	Default
`log`	No
`job_id`	No
`truncated`	No
`bytes_read`	No
`total_lines`	No
`grep_matches`	No
`grep_pattern`	No
`showing_last`	No
`output_truncated`	No
`matches_truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.5.5Nov 5, 2026

removedInput schema / properties / project_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / project_path / default
```
Removed value: -null
```

changedInput schema / properties / project_path / description

Previous value: -"GitLab project path (e.g. 'my-org/my-repo'). When omitted, the default from GITLAB_PROJECT_PATH env var is used."New value: +"GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted."

addedInput schema / properties / project_path / minLength
```
Added value: +1
```
addedInput schema / properties / project_path / type
```
Added value: +"string"
```

changedInput schema / required

Previous value: -[
-  "job_id"
-]New value: +[
+  "job_id",
+  "project_path"
+]

addedOutput schema / properties / bytes_read

Added value: +{
+  "default": null,
+  "title": "Bytes Read",
+  "type": "integer"
+}

addedOutput schema / properties / matches_truncated

Added value: +{
+  "default": null,
+  "title": "Matches Truncated",
+  "type": "boolean"
+}

addedOutput schema / properties / output_truncated

Added value: +{
+  "default": null,
+  "title": "Output Truncated",
+  "type": "boolean"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "default": null,
+  "title": "Truncated",
+  "type": "boolean"
+}

First observedv0.5.1Apr 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavior beyond them: grep mode replaces tail semantics entirely, invalid regex silently falls back to literal substring matching, and tail is capped at 5000 for token efficiency. It does not discuss output shape, but an output schema exists, so that gap is acceptable.

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?

Strongly front-loaded with the one-line purpose followed by the mode split, and every sentence carries information. The four example bullets are slightly verbose, and the tail=5000 'scan for stage separator' example is marginally less crisp, but overall the structure aids fast scanning.

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?

For a five-parameter read tool with full schema descriptions, rich annotations, and an output schema, the description covers everything an agent needs: what it returns in each mode, token-cost tradeoffs, and error-fallback behavior. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning the schema alone doesn't convey: the mutual exclusivity of tail vs grep_pattern and how grep_context interacts with matches. The examples also demonstrate practical value ranges (tail=100, grep_context=5) that contextualize the numeric parameters.

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?

Opens with a specific verb+resource: 'Fetch the trace/log of a job, with optional regex filter.' It clearly separates this from sibling tools like gitlab_get_pipeline_jobs (which enumerates jobs) by emphasizing that this retrieves the log content of a single job.

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 lays out two usage modes with selection criteria — default tail for 'why did this just fail?' versus grep mode for megabyte-scale logs. The examples map real user questions ('Why did job 789 fail', 'Find every Traceback') directly to parameter choices, leaving little inference needed.

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