## Proposal Add support for new MCP tool: `get_job_log` which maps to [`Get a log (trace) of a specific job`](https://docs.gitlab.com/ee/api/jobs.html#get-a-log-trace-of-a-specific-job) * Add a new API mapping following our framework/annotation approach * Allow the following arguments from the API documentation * `id` (required) - The ID or URL-encoded path of the project * `job_id` (required) - The ID of a job ```ruby route_setting :mcp, tool_name: :get_job_log, params: [:id, :job_id] ``` ### Use case The MCP server currently supports `get_pipeline_jobs` to list jobs and their status, but there is no way to read the actual log output of a job. AI-assisted CI/CD debugging workflows need to read failing job logs to diagnose compilation errors, test failures, and lint issues. Without this tool, users must fall back to raw API calls (`/projects/:id/jobs/:job_id/trace`). This is referenced in the planning roadmap (#562157) and governance issue (#567747, listed as `get_job_logs` with `pipeline:logs` scope) but has no standalone implementation issue. **Note:** The job trace endpoint returns plain text and can be large. Consider supporting optional `line_count` or byte-range parameters to allow truncated retrieval, or truncate server-side to a reasonable limit. **Parent Epic:** https://gitlab.com/groups/gitlab-org/-/epics/20529