gitlab-api

Get project job

gitlab_get_project_job

Read-onlyIdempotent

Retrieve details for a specific GitLab project job using project_id and job_id, returning the job model and response wrapper for inspection.

Instructions

Get details of a specific job within a project.

Args: **kwargs: Additional parameters for the request (e.g., project_id, job_id).

Returns: Response: A wrapper containing the original response and a Job model.

Raises: MissingParameterError: If the project_id or job_id is missing. ParameterError: If invalid parameters are provided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gitlab_get_project_job"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No
`scope`	No
`job_id`	No
`per_page`	No
`max_pages`	No
`project_id`	No
`pipeline_id`	No
`total_pages`	No
`include_retried`	No
`job_variable_attributes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

First observedv27.3.13Oct 25, 2026

TDQS

B3.1/5.0

Behavior4/5

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

The annotations already establish read-only, idempotent, open-world, and non-destructive behavior, so the description adds useful extra context: it names the return wrapper and Job model and discloses error conditions for missing project_id/job_id or invalid parameters. It does not explain pagination behavior, but it adds meaningful behavioral detail beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the Args/Returns/Raises structure is easy to scan. However, the Args section is generic and misleading for a tool with 10 explicit parameters, reducing the value of the otherwise compact formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only job lookup, the description gives the core identifiers, return wrapper, and error conditions, which is enough to attempt the call. It remains incomplete for a 10-parameter tool with no schema descriptions because most parameters and pagination behavior are not addressed.

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

Parameters2/5

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

The schema has 10 parameters with 0% description coverage, and the description only mentions project_id and job_id as examples under **kwargs. It leaves page, per_page, scope, max_pages, total_pages, pipeline_id, include_retried, and job_variable_attributes unexplained, so it does not compensate for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: get details of a specific job within a project. This distinguishes it reasonably from list-style siblings like gitlab_get_project_jobs and log-oriented gitlab_get_project_job_log, though it does not explicitly name those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by saying it gets details of a specific job, but it does not say when to use this instead of gitlab_get_project_jobs, gitlab_get_pipeline_jobs, gitlab_get_project_job_log, or the GraphQL job tool. No explicit exclusions or routing guidance are provided.

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

Deploy Server