Gitlab Ci MCP vs MCP Server Atlassian Bitbucket
A side-by-side look at the Gitlab Ci MCP and MCP Server Atlassian Bitbucket MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Gitlab Ci MCP for version control work as a local process; choose MCP Server Atlassian Bitbucket for version control as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Gitlab Ci MCP when
- You need dedicated capabilities in the Version Control domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
GITLAB_URL, GITLAB_TOKEN, GITLAB_PROJECT_PATH, GITLAB_SSL_VERIFY, GITLAB_NO_PROXY_DOMAINS. - You want tools like
gitlab_list_branches, gitlab_list_tags, gitlab_compare_branches.
Choose MCP Server Atlassian Bitbucket when
- You need dedicated capabilities in the Version Control domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
ATLASSIAN_USER_EMAIL, ATLASSIAN_API_TOKEN, ATLASSIAN_BITBUCKET_USERNAME, ATLASSIAN_BITBUCKET_APP_PASSWORD, BITBUCKET_DEFAULT_WORKSPACE. - You want tools like
bb_get, bb_post, bb_put.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Version Control | Version Control |
| Quality signal | 57/100 · Good | 65/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | API key required | API key required |
| Pricing | BYOK (pay the provider) | Free |
| Required env vars | GITLAB_URLGITLAB_TOKENGITLAB_PROJECT_PATHGITLAB_SSL_VERIFYGITLAB_NO_PROXY_DOMAINS | ATLASSIAN_USER_EMAILATLASSIAN_API_TOKENATLASSIAN_BITBUCKET_USERNAMEATLASSIAN_BITBUCKET_APP_PASSWORDBITBUCKET_DEFAULT_WORKSPACE |
| Verified owner | Community listing | Community listing |
| GitHub stars | 2 | 163 |
| Directory activity | 3 views 0 installs 0 upvotes | 6 views 0 installs 0 upvotes |
| Tools | 23 | 6 |
| Full listing | View Gitlab Ci MCP | View MCP Server Atlassian Bitbucket |
Tools & capabilities
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
MCP Server Atlassian Bitbucket tools 6
bb_getRead any Bitbucket data. Returns TOON format by default (30-60% fewer tokens than JSON). **IMPORTANT - Cost Optimization:** - ALWAYS use `jq` param to filter response fields. Unfiltered responses are very expensive! - Use `pagelen` query param to restrict result count (e.g., `pagelen: "5"`) - If unsure about available fields, first fetch ONE item with `pagelen: "1"` and NO jq filter to explore the schema, then use jq in subsequent calls **Schema Discovery Pattern:** 1. First call: `path: "/workspaces", queryParams: {"pagelen": "1"}` (no jq) - explore available fields 2. Then use: `jq: "values[*].{slug: slug, name: name, uuid: uuid}"` - extract only what you need **Output format:** TOON (default, token-efficient) or JSON (`outputFormat: "json"`) **Common paths:** - `/workspaces` - list workspaces - `/repositories/{workspace}` - list repos in workspace - `/repositories/{workspace}/{repo}` - get repo details - `/repositories/{workspace}/{repo}/pullrequests` - list PRs - `/repositories/{workspace}/{repo}/pullrequests/{id}` - get PR details - `/repositories/{workspace}/{repo}/pullrequests/{id}/comments` - list PR comments - `/repositories/{workspace}/{repo}/pullrequests/{id}/diff` - get PR diff - `/repositories/{workspace}/{repo}/refs/branches` - list branches - `/repositories/{workspace}/{repo}/commits` - list commits - `/repositories/{workspace}/{repo}/src/{commit}/{filepath}` - get file content - `/repositories/{workspace}/{repo}/diff/{source}..{destination}` - compare branches/commits **Query params:** `pagelen` (page size), `page` (page number), `q` (filter), `sort` (order), `fields` (sparse response) **Example filters (q param):** `state="OPEN"`, `source.branch.name="feature"`, `title~"bug"` **JQ examples:** `values[*].slug`, `values[0]`, `values[*].{name: name, uuid: uuid}` The `/2.0` prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/bb_postCreate Bitbucket resources. Returns TOON format by default (token-efficient). **IMPORTANT - Cost Optimization:** - Use `jq` param to extract only needed fields from response (e.g., `jq: "{id: id, title: title}"`) - Unfiltered responses include all metadata and are expensive! **Output format:** TOON (default) or JSON (`outputFormat: "json"`) **Common operations:** 1. **Create PR:** `/repositories/{workspace}/{repo}/pullrequests` body: `{"title": "...", "source": {"branch": {"name": "feature"}}, "destination": {"branch": {"name": "main"}}}` 2. **Add PR comment:** `/repositories/{workspace}/{repo}/pullrequests/{id}/comments` body: `{"content": {"raw": "Comment text"}}` 3. **Approve PR:** `/repositories/{workspace}/{repo}/pullrequests/{id}/approve` body: `{}` 4. **Request changes:** `/repositories/{workspace}/{repo}/pullrequests/{id}/request-changes` body: `{}` 5. **Merge PR:** `/repositories/{workspace}/{repo}/pullrequests/{id}/merge` body: `{"merge_strategy": "squash"}` (strategies: merge_commit, squash, fast_forward) The `/2.0` prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/bb_putReplace Bitbucket resources (full update). Returns TOON format by default. **IMPORTANT - Cost Optimization:** - Use `jq` param to extract only needed fields from response - Example: `jq: "{uuid: uuid, name: name}"` **Output format:** TOON (default) or JSON (`outputFormat: "json"`) **Common operations:** 1. **Update repository:** `/repositories/{workspace}/{repo}` body: `{"description": "...", "is_private": true, "has_issues": true}` 2. **Create/update file:** `/repositories/{workspace}/{repo}/src` Note: Use multipart form data for file uploads (complex - prefer PATCH for metadata) 3. **Update branch restriction:** `/repositories/{workspace}/{repo}/branch-restrictions/{id}` body: `{"kind": "push", "pattern": "main", "users": [{"uuid": "..."}]}` The `/2.0` prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/bb_patchPartially update Bitbucket resources. Returns TOON format by default. **IMPORTANT - Cost Optimization:** Use `jq` param to filter response fields. **Output format:** TOON (default) or JSON (`outputFormat: "json"`) **Common operations:** 1. **Update PR title/description:** `/repositories/{workspace}/{repo}/pullrequests/{id}` body: `{"title": "New title", "description": "Updated description"}` 2. **Update PR reviewers:** `/repositories/{workspace}/{repo}/pullrequests/{id}` body: `{"reviewers": [{"uuid": "{user-uuid}"}]}` 3. **Update repository properties:** `/repositories/{workspace}/{repo}` body: `{"description": "New description"}` 4. **Update comment:** `/repositories/{workspace}/{repo}/pullrequests/{pr_id}/comments/{comment_id}` body: `{"content": {"raw": "Updated comment"}}` The `/2.0` prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/bb_deleteDelete Bitbucket resources. Returns TOON format by default. **Output format:** TOON (default) or JSON (`outputFormat: "json"`) **Common operations:** 1. **Delete branch:** `/repositories/{workspace}/{repo}/refs/branches/{branch_name}` 2. **Delete PR comment:** `/repositories/{workspace}/{repo}/pullrequests/{pr_id}/comments/{comment_id}` 3. **Decline PR:** `/repositories/{workspace}/{repo}/pullrequests/{id}/decline` 4. **Remove PR approval:** `/repositories/{workspace}/{repo}/pullrequests/{id}/approve` 5. **Delete repository:** `/repositories/{workspace}/{repo}` (caution: irreversible) Note: Most DELETE endpoints return 204 No Content on success. The `/2.0` prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/bb_cloneClone a Bitbucket repository to your local filesystem using SSH (preferred) or HTTPS. Provide `repoSlug` and `targetPath` (absolute path). Clones into `targetPath/repoSlug`. SSH keys must be configured; falls back to HTTPS if unavailable.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Gitlab Ci MCP
{
"mcpServers": {
"mshegolev-gitlab-ci-mcp": {
"command": "uvx",
"args": [
"--from",
"gitlab-ci-mcp",
"gitlab-ci-mcp"
],
"env": {
"GITLAB_URL": "YOUR_GITLAB_URL_HERE",
"GITLAB_TOKEN": "YOUR_GITLAB_TOKEN_HERE",
"GITLAB_PROJECT_PATH": "YOUR_GITLAB_PROJECT_PATH_HERE",
"GITLAB_SSL_VERIFY": "YOUR_GITLAB_SSL_VERIFY_HERE",
"GITLAB_NO_PROXY_DOMAINS": "YOUR_GITLAB_NO_PROXY_DOMAINS_HERE"
}
}
}
}
MCP Server Atlassian Bitbucket
{
"mcpServers": {
"aashari-mcp-server-atlassian-bitbucket": {
"command": "npx",
"args": [
"-y",
"@aashari/mcp-server-atlassian-bitbucket"
],
"env": {
"ATLASSIAN_USER_EMAIL": "YOUR_ATLASSIAN_USER_EMAIL_HERE",
"ATLASSIAN_API_TOKEN": "YOUR_ATLASSIAN_API_TOKEN_HERE",
"ATLASSIAN_BITBUCKET_USERNAME": "YOUR_ATLASSIAN_BITBUCKET_USERNAME_HERE",
"ATLASSIAN_BITBUCKET_APP_PASSWORD": "YOUR_ATLASSIAN_BITBUCKET_APP_PASSWORD_HERE",
"BITBUCKET_DEFAULT_WORKSPACE": "YOUR_BITBUCKET_DEFAULT_WORKSPACE_HERE"
}
}
}
}
Frequently asked questions
Gitlab Ci MCP is categorized under Version Control and uses a local stdio subprocess. MCP Server Atlassian Bitbucket belongs to Version Control and uses a local stdio subprocess. Pick Gitlab Ci MCP for version control work and MCP Server Atlassian Bitbucket for version control.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Gitlab Ci MCP is bring-your-own-key: usage is billed by the API provider you supply a key for. Auth: api key required. MCP Server Atlassian Bitbucket is listed as free. Auth: api key required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add mshegolev-gitlab-ci-mcp and aashari-mcp-server-atlassian-bitbucket as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Gitlab Ci MCP has a quality signal of 57/100 (Good) with 3 views, 0 installs and 2 GitHub stars. MCP Server Atlassian Bitbucket has 65/100 (Great) with 6 views, 0 installs and 163 GitHub stars.