Git vs Gitlab Ci MCP

Git tools

No tool names declared yet. Check the project README from the listing page.

Gitlab Ci MCP tools 23

• gitlab_list_branchesList branches of a project, optionally filtered by substring. Includes ``default``, ``protected`` and ``merged`` flags, and the short id of the tip commit with its title and date. Examples: - "List all branches with 'release' in name" → ``search='release'`` - "Next page of branches" → ``page=2`` - Don't use when you want to check if a specific branch exists by exact name — use ``gitlab_get_file`` on that ref and look at the error instead.
• gitlab_list_tagsList tags of a project, newest first. Useful for release-note generation or checking the last shipped version. Examples: - "What was the last release tag" → default call, take the first item - "All v2.x releases" → ``search='v2.'``
• gitlab_compare_branchesCompare two branches — returns up to 30 commits and the list of changed files. Use for "what's in ``release/x.y`` vs ``master``?" or for release-note drafting. Examples: - "What's new in release/1.5 vs master" → ``source='release/1.5'``, ``target='master'`` - Don't use to fetch full diffs of an MR — use ``gitlab_get_merge_request_changes``.
• gitlab_list_merge_requestsList merge requests of a project, optionally filtered by state. Examples: - "What MRs are open right now" → default (state='opened') - "What merged last week" → ``state='merged'`` then filter by ``updated_at`` client-side - "Everything regardless of state" → ``state='all'`` - Don't use when you have an MR IID — use ``gitlab_get_merge_request`` for detail.
• gitlab_get_merge_requestGet full information about a merge request by internal ID (``iid``). Includes state, branches, author, assignees, reviewers, labels, conflict status, description and timestamps. Examples: - "Show me the description and state of !42" → ``mr_iid=42`` - Don't use to see changed files — use ``gitlab_get_merge_request_changes``.
• gitlab_get_merge_request_changesList changed files in a merge request with truncated diffs (2KB per file). Useful for code-review-style queries ("what changed in !42?"). Diffs beyond 2KB are truncated — fetch the raw file via ``gitlab_get_file`` for full content. Examples: - "What did MR !42 change" → ``mr_iid=42`` - If you need full content of a changed file, use ``gitlab_get_file`` with the MR's source branch.
• gitlab_create_merge_requestCreate a merge request from ``source_branch`` into ``target_branch``. **Not idempotent**: creates a new MR each call. Check existing MRs first via ``gitlab_list_merge_requests`` if you want to avoid duplicates. Examples: - "Open an MR from feature/login to master" → ``source_branch='feature/login'`` - "Open a WIP MR with a label" → ``title='Draft: ...'``, ``labels=['wip']`` - Don't use to merge an already-open MR — use ``gitlab_merge_mr``.
• gitlab_merge_mrPerform the actual merge if GitLab reports the MR can be merged. **Destructive**: writes to the target branch. Checks ``merge_status`` first and returns ``status='cannot_merge'`` if conflicts exist or pipelines are required. Examples: - "Merge !42" → ``mr_iid=42`` - Don't call without checking ``gitlab_get_merge_request`` first when you suspect conflicts.
• gitlab_list_pipelinesList recent pipelines of a project, newest first. Use for triage ("show failed pipelines on master"), release readiness checks, or feeding pipeline IDs into follow-up calls. Read-only and idempotent. Returns ``PipelinesListOutput``: ``project``, ``count``, ``pagination`` and ``pipelines[]`` (each ``PipelineSummary``). The tool result additionally carries a markdown table in its text content. Examples: - "Show failed pipelines on master" → ``status='failed'``, ``ref='master'`` - "Last nightly schedule runs" → ``source='schedule'`` - "Second page of pipelines" → ``page=2`` - Don't use when you have a specific pipeline ID — use ``gitlab_get_pipeline`` instead.
• gitlab_get_pipelineGet a single pipeline with full timing details. Useful right after ``gitlab_list_pipelines`` — lists only return summaries. Returns status, ref, source, durations (queued/total), and started/finished timestamps. Examples: - "Why was pipeline 123 slow" → check ``queued_duration`` and ``duration`` fields - "Is pipeline 456 still running" → look at ``status`` - Don't use to see individual jobs — use ``gitlab_get_pipeline_jobs``.
• gitlab_get_pipeline_jobsList jobs of a pipeline with stage, status, duration and web URL. Use after noticing a failed pipeline to drill down into which specific job broke and fetch its log via ``gitlab_get_job_log``. Examples: - "What jobs are in pipeline 123" → ``pipeline_id=123`` - "Which job failed in pipeline 456" → filter result by ``status='failed'`` client-side - Don't use for overall pipeline status — use ``gitlab_get_pipeline`` instead.
• gitlab_get_job_logFetch 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'``
• +11 more on the listing page