Skip to main content
Glama

gitlab_get_job_log

Read-onlyIdempotent

Retrieve GitLab CI job logs with optional filtering to find specific errors or view recent output, enabling efficient debugging of pipeline failures.

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'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesNumeric job ID (from ``gitlab_get_pipeline_jobs``).
tailNoReturn only the last N lines (1–5000, default 100).
grep_patternNoOptional 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.
grep_contextNoSurrounding lines to include around each grep match (0–20).
project_pathNoGitLab project path (e.g. 'my-org/my-repo'). When omitted, the default from GITLAB_PROJECT_PATH env var is used.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idNo
total_linesNo
showing_lastNo
logNo
grep_patternNo
grep_matchesNo
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context: it explains the two operational modes, mentions token-efficiency considerations, and notes that invalid regex falls back to literal substring match. While it doesn't cover rate limits or auth needs, it provides meaningful operational guidance beyond annotations.

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 well-structured with clear sections (overview, two modes, examples). Every sentence earns its place: the opening defines purpose, the mode descriptions explain behavior, and examples illustrate practical use. No redundant information, and the content is front-loaded with the core functionality.

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?

Given the tool's moderate complexity (5 parameters, two operational modes), the description provides complete context. It explains the tool's behavior, parameter interactions, and use cases. With annotations covering safety/idempotency and an output schema existing (though not shown), the description focuses appropriately on operational guidance without needing to explain return values.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the semantic relationship between parameters: it clarifies that grep_pattern enables a different mode (vs default tail mode), describes how grep_context works with grep_pattern, and provides concrete examples showing parameter combinations. This goes beyond the schema's individual parameter descriptions.

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 fetches job logs/traces with optional filtering. It specifies the exact resource (job log/trace) and distinguishes from siblings like gitlab_get_pipeline_jobs (which lists jobs, not their logs). The opening sentence 'Fetch the trace/log of a job, with optional regex filter' provides specific verb+resource+scope.

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?

The description provides explicit guidance on when to use each mode: default mode for 'why did this just fail?' and grep mode for 'finding errors in megabyte-scale CI logs without pulling the whole trace.' The examples illustrate specific scenarios (e.g., 'Show me the first stage output' vs 'Find every Traceback'), giving clear alternatives within the tool itself.

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/mshegolev/gitlab-ci-mcp'

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