Bitbucket MCP Server
You can use this MCP server to interact with Bitbucket repositories, branches, files, commits, and pull requests on behalf of an AI agent.
Browse projects/repositories and list branches or directory contents.
Read file content, including server-side line windows or full-file/tail reads.
List and inspect pull requests, including metadata, comments, tasks, changed files, reviewer status, and merge info.
Create, update, merge, decline, and list pull requests, including cross-repository PR dashboards.
Get raw unified PR diffs with file/glob scoping and context controls.
Add comments (general, threaded, inline, code suggestions, or tasks) and edit/delete/resolve/reopen/convert comments and tasks.
Set your review status: approve, request changes, or clear approval.
List PR commits and branch commits, and inspect commit diffs or changed-file lists.
Delete branches with optional expected-head compare-and-swap.
Use safety controls from the README such as read-only mode, disabled tools, protected branches, and rate-limit pacing.
Provides tools for interacting with the Bitbucket API, supporting both Bitbucket Cloud and Bitbucket Server. Enables management of pull requests (creating, updating, listing, approving, commenting), handling code reviews, working with branches, and viewing diffs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Bitbucket MCP Server list my open pull requests in the web-app repository"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Bitbucket MCP Server
MCP server for Bitbucket — built for AI coding agents that need to work with remote repositories as if they were local clones: grep-fast code search, windowed file reads, compact token-efficient responses, and a transport layer that never trips Bitbucket's rate limits.
Supports Bitbucket Server / Data Center (primary target) and Bitbucket Cloud.
Why v3
v2 | v3 | |
Content search in a repo | 1 listing + up to 3,000 file GETs | 1 archive call cold, 0–1 calls warm |
Search completeness | silently partial under server throttling | complete, with every cap reported |
PR diff tokens | per-line JSON (~4× larger) | raw unified diff |
Read a 100-line window | 2 calls, full file transferred | 1 call, window only |
Blame a window of a huge file | up to 100 calls | 1 call |
Rate-limit safety | none (burst → 429/403) | client-side pacing sized to DC's limiter |
Tools | 33 | 25 (~30% less definition context) |
Measured on a live Data Center instance: a repeated content search went from 519 API calls / ~7s (finding 1 of 8 real matches under burst throttling) to 0 API calls / 24ms finding all 8. Full design and verified API research: REVAMP_PLAN.md.
Related MCP server: bitbucket-mcp-server
Tools (25)
Search (search) — Server/DC only
grep— search file contents with full regex, any branch, like ripgrep on a local clone. Onearchivedownload per repo+commit, streamed in constant memory, cached in-process, freshness-checked every call (responses carryas_of <commit>). Omitqueryfor filename-only glob listing. Modes:content,files,count;glob,path,context,case_insensitive,max_results.search_code— index-backed exact-term search across a whole project in one call (default branch only, case-insensitive, no regex, files <512 KiB, ~1000-result window). Best for cross-repo identifier lookups; usegrepfor everything else.search_repositories— find repos by name/description.
Pull requests (pr_core)
get_pull_request— metadata + reviewer status + merge info in 1 call;include_comments/include_file_changes(default true),include_tasks,comment_limit. Returnsversionfor follow-up mutations.list_pull_requests— repo-scoped; omitrepository(Server) for your PRs across all repos in one call (rolefilter).create_pull_request,update_pull_request,merge_pull_request,decline_pull_request— all mutations acceptversionfrom a prior read (saves a fetch; auto-refetch + retry once on 409 conflicts).
Comments & tasks (pr_comments)
add_comment— general, threaded reply, inline (file_path+line_number, orcode_snippetauto-resolution), codesuggestion, or task (severity: "BLOCKER", Server). Attachments upload via theattachmentsparam (Server).manage_comment—edit/delete/resolve/reopen/to_task/to_commenton any comment or task, one call withversion.
Review (pr_review)
get_pull_request_diff— raw unified diff text; scope withfile_path(server-side),include_patterns/exclude_patterns,context_lines,ignore_whitespace.set_review_status—APPROVED/NEEDS_WORK/UNAPPROVED(mutually exclusive; one call).
Commits (commits)
list_pr_commits,list_branch_commits(server-sidesince-rev/mergesfilters; bounded page-walk for client-sideauthor/until/search),get_commit_detail(unified diff, ordetail: "files"for the changed-file list without bodies).
Branches (branches)
list_branches,get_branch(branch + its PRs),delete_branch(expected_headskips the lookup call).
Files (files)
get_file_content— windowed server-side:start_line/line_counttransfer only that window (≤5000 lines/call).full_content/ negativestart_linefor whole-file or tail reads.get_file_blame— commit-span blame for a line window in 1 call (Server).list_directory_content— paginated, compact.
Attachments (attachments, Server) / Discovery (discovery)
manage_attachments(downloadcapped,delete),list_projects,list_repositories.
Output conventions
Bulk content (diffs, files, grep results) is plain text, not JSON-escaped strings; lists are compact JSON without pretty-printing. Dates are ISO-8601.
Content-derived responses carry
as_of <commit>so the agent knows exactly which state it saw.Truncation is never silent — every cap produces an explicit warning with continuation guidance (
next_start, "narrow the glob", etc.).Mutable entities include
version, so mutations don't need a re-read.
Installation
Requires Node.js 22 or newer (18 and 20 are end-of-life and no longer receive security fixes).
Using npx (recommended)
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": ["-y", "@nexus2520/bitbucket-mcp-server"],
"env": {
"BITBUCKET_USERNAME": "your.username",
"BITBUCKET_TOKEN": "your-http-access-token",
"BITBUCKET_BASE_URL": "https://bitbucket.yourcompany.com"
}
}
}
}For Bitbucket Cloud use BITBUCKET_APP_PASSWORD instead of BITBUCKET_TOKEN (and omit BITBUCKET_BASE_URL).
Credential walkthroughs: Cloud app password · Server/DC HTTP token.
From source
git clone https://github.com/pdogra1299/bitbucket-mcp-server.git
cd bitbucket-mcp-server
npm install && npm run build
# point your MCP config at: node <repo>/build/index.jsConfiguration
Every numeric policy is environment-tunable — nothing is hard-coded. The full table lives in src/config/index.ts (CONFIG_REFERENCE). The ones that matter most:
Variable | Default | Purpose |
|
| Client-side sustained request rate (DC's per-user refill is 5/s). |
|
| Burst capacity (DC's server bucket is 60) |
|
| Max in-flight requests across all tools |
|
| In-memory grep cache budget. |
|
| Files larger than this are scanned but not cached |
|
| Branch→SHA freshness memo; |
|
| Abort archive scans past this many extracted MB (falls back to bounded per-file scan) |
|
| Per-request timeout |
| all | Comma-separated groups to expose (validated, enforced at dispatch, fails closed) |
|
| Hide and refuse every state-changing tool (create/update/merge/decline PR, comments, review status, delete branch, attachment delete) |
| — | Comma-separated tool names to hide and refuse regardless of group |
| — | Branch names/globs ( |
| unset = uploads disabled | The only directory attachment uploads may read from (realpath-confined, regular files only) |
|
| Size caps for attachment upload / download |
|
| Wall-clock budget per content scan; exceeding it returns marked PARTIAL results |
|
| Lines longer than this are counted and reported, not regex-scanned (bounds per-line regex cost on minified files) |
The grep engine's guarantees
Memory-bounded: the archive is streamed, never buffered whole; the cache is a hard byte budget with LRU eviction and content-hash dedup across branches. Worst case = budget + a few MB transient.
Fresh: every query re-resolves the branch head; a moved branch can never serve stale results. Merges/deletes made through this server invalidate immediately.
Complete: cache limits never reduce scan coverage — oversized files are still scanned; only true binaries are skipped, and they're counted in the output.
Rate limiting
All requests flow through a token bucket sized to Bitbucket DC's per-user limiter, so 429s are avoided rather than retried-after. If your instance throttles hard anyway, the error message says exactly what to do — the durable fix is asking a Bitbucket admin for a rate-limit exemption for the service account (Admin → Rate limiting → Exemptions), then setting BITBUCKET_RATE_LIMIT_RPS=0.
Security
This server executes tool calls whose arguments come from an LLM, often with a write-capable token. The following controls are built in:
Least privilege by configuration.
BITBUCKET_READ_ONLY=trueremoves every mutating tool from bothtools/listand dispatch — recommended for autonomous agents that only need to read PRs, diffs and code.BITBUCKET_DISABLED_TOOLSdrops individual tools;BITBUCKET_PROTECTED_BRANCHESblocksdelete_branch/merge_pull_requestagainst named branches or globs. Every tool carries MCPreadOnlyHint/destructiveHintannotations so clients can gate confirmations.No request steering.
workspace,repository, commit ids, attachment ids and file paths are charset-validated and percent-encoded per URL segment, so a value likePROJ/../../adminorrepo?limit=1000can never change the REST route a fixed-verb tool hits.Attachment uploads are opt-in and sandboxed. Without
BITBUCKET_ATTACHMENT_ROOTtheattachmentsparameter is refused. With it, the real (symlink-resolved) path must stay inside the root, be a regular file, and fit the size cap; every rejection uses one generic message so the tool is not a filesystem existence oracle. Downloads are size-capped too.Regex denial-of-service guard. Caller regexes (
grepquery,search_coderegex_filter) are length-capped, rejected statically when an unbounded quantifier wraps a group with undelimited variable-width repetition ((a+)+,(\w+\s*)*), probed against adversarial inputs under a vm timeout, and every scan runs against a wall-clock deadline (BITBUCKET_GREP_TIMEOUT_MS) with partial results marked, never silent. Lines longer thanBITBUCKET_GREP_MAX_SCAN_LINE_CHARSare skipped and counted. V8's linear-time regexp fallback is enabled at startup as an extra layer.Credential hygiene. Transport errors are normalized to status + message + response headers before they reach handlers; error objects are never logged whole, and log lines are scrubbed for
Authorization-style values. Cloud pagination followsnextURLs only on the configured origin.Dependency floor. Node ≥ 22;
npm run audit:prodmust report zero high/critical advisories for the published tree (enforced in CI).
Recommended deployment for an autonomous agent:
"env": {
"BITBUCKET_READ_ONLY": "true",
"BITBUCKET_PROTECTED_BRANCHES": "main,release/*"
}Writes (comments, approvals, merges) should then run through a separate, human-confirmed server instance or the hosting application's own approval flow.
Migrating from v2
Removed tools and their v3 equivalents (same capabilities, fewer tools):
v2 | v3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update Claude Code permission allowlists (mcp__bitbucket__*) accordingly. Diff tools now return unified diff text instead of per-line JSON — line numbers come from @@ headers. Full details in CHANGELOG.md.
Development
npm run build # tsc → build/
npm test # build + node --test (unit + snapshot-engine tests)Architecture: src/config (all policy) · src/core (transport, snapshot engine, caches) · src/handlers (tool logic) · src/tools (definitions, guards, registry) · src/formatting (compact output) · src/types (single barrel).
License
MIT
Available Tools
20 toolsadd_commentA
Add a PR comment: general, threaded reply (parent_comment_id), inline (file_path + line_number), code suggestion (suggestion), or task (severity BLOCKER, Server only). code_snippet auto-resolves line_number from exact diff text when line_number is unknown.
Inputs: workspace (required), repository (required), comment_text (required), pull_request_id (required), +11 more.
create_pull_requestD
Create a pull request.
Inputs: title (required), workspace (required), repository (required), source_branch (required), +5 more.
decline_pull_requestADestructiveIdempotent
Decline a pull request, optionally with a comment. Pass version to save a fetch (Server).
Inputs: workspace (required), repository (required), pull_request_id (required), comment, +1 more.
delete_branchADestructiveIdempotent
Delete a branch. Pass expected_head (commit SHA) to skip the lookup call (Server).
Inputs: workspace (required), repository (required), branch_name (required), expected_head.
get_branchARead-only
Get a branch with its latest commit and open PRs (include_merged_prs adds merged ones).
Inputs: workspace (required), repository (required), branch_name (required), include_merged_prs.
get_commit_detailARead-only
Get a commit diff as raw unified diff text, or detail:"files" for just the changed-file list (no diff bodies).
Inputs: commit_id (required), workspace (required), repository (required), detail, +4 more.
get_file_contentARead-only
Read a file. Windowed by default (start_line/line_count fetch ONLY that window server-side; ≤5000 lines per call). full_content=true or negative start_line (tail) fetches the whole file — prefer windows.
Inputs: file_path (required), workspace (required), repository (required), branch, +3 more.
get_pull_requestARead-only
Get a pull request: metadata, reviewer status, merge info, comments and changed files. Set include_comments/include_file_changes false for a 1-call metadata read; include_tasks lists open/resolved tasks. Response carries version for follow-up mutations.
Inputs: workspace (required), repository (required), pull_request_id (required), comment_limit, +3 more.
get_pull_request_diffARead-only
Get a PR diff as raw unified diff text (line numbers derive from @@ headers; +/- prefixes mark ADDED/REMOVED). Scope with file_path (server-side) or include/exclude glob patterns.
Inputs: workspace (required), repository (required), pull_request_id (required), file_path, +4 more.
list_branch_commitsARead-only
List commits on a branch. since (as a rev) and include_merge_commits filter server-side; author/until/search and date-valued since filter client-side over a bounded page walk (noted when more pages exist).
Inputs: workspace (required), repository (required), branch_name (required), limit, +7 more.
list_branchesBRead-only
List branches (most recently modified first on Server).
Inputs: workspace (required), repository (required), limit, start, +1 more.
list_directory_contentBRead-only
List files and directories at a repository path.
Inputs: workspace (required), repository (required), path, branch.
list_pr_commitsCRead-only
List commits in a pull request.
Inputs: workspace (required), repository (required), pull_request_id (required), limit, +2 more.
list_projectsBRead-only
List accessible projects/workspaces.
Inputs: name, limit, start, permission.
list_pull_requestsARead-only
List pull requests in a repository. Omit repository (Server only) to list YOUR PRs across all repos in one call (filter with role).
Inputs: workspace (required), role, limit, start, +3 more.
list_repositoriesARead-only
List repositories in a project (or all accessible on Server).
Inputs: name, limit, start, workspace, +1 more.
manage_commentADestructiveIdempotent
Edit/delete/resolve/reopen a PR comment or task, or convert between comment and task (to_task/to_comment are Server-only). Pass version (from get_pull_request output) to save a fetch (Server).
Inputs: action (required), workspace (required), comment_id (required), repository (required), +3 more.
merge_pull_requestCDestructive
Merge a pull request. Pass version to save a fetch.
Inputs: workspace (required), repository (required), pull_request_id (required), version, +3 more.
set_review_statusAIdempotent
Set YOUR reviewer status on a PR: APPROVED, NEEDS_WORK (request changes), or UNAPPROVED (clear). One call; the three states are mutually exclusive.
Inputs: status (required), workspace (required), repository (required), pull_request_id (required), +1 more.
update_pull_requestAIdempotent
Update a pull request. Reviewers/approvals are preserved unless reviewers is passed. Pass version (from get/list) to save a fetch.
Inputs: workspace (required), repository (required), pull_request_id (required), title, +5 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 20 tools
Most tools target clearly distinct resources and actions (PRs, commits, branches, files, projects). Minor overlap exists between get_pull_request (which can include file changes) and get_pull_request_diff, and between list_pr_commits and list_branch_commits, but descriptions clarify the boundaries. add_comment vs manage_comment is well differentiated by verb.
Every tool follows a consistent snake_case verb_noun pattern (get_/list_/create_/update_/merge_/decline_/add_/manage_/set_/delete_). The resource noun is predictable throughout, making the surface highly readable.
20 tools cover several resource domains (PRs, commits, branches, files, projects/repos), so the count is justified but sits at the heavier end. Each tool maps to a distinct operation rather than redundant variants.
PR lifecycle is thoroughly covered (create/list/get/update/merge/decline, comments, review status, diff, commits). Gaps exist: branches support get/list/delete but no create_branch, and files/projects/repos are read-only, though these may be intentional for a review-focused server.
Maintenance
Related MCP Connectors
A MCP server built for developers enabling Git based project management with project and personal…
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
MCP Server for JFrog, providing tools for development and artifact management.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that provides tools for interacting with the Bitbucket API, supporting both Bitbucket Cloud and Bitbucket Server, enabling pull request, branch, file, code review, and search operations.198,411 npmMIT
- AlicenseBqualityCmaintenanceA Model Context Protocol (MCP) server that provides tools for interacting with Bitbucket repositories, pull requests, issues, and more.1741 npmISC
- AlicenseBqualityDmaintenanceAn MCP server for Bitbucket Cloud that enables managing pull requests, branches, and repositories in natural language from any MCP-capable client.23387 npm4MIT
- AlicenseBqualityBmaintenanceMCP server for Bitbucket Server integration, enabling project, repository, pull request, source code, branch, and code review operations via the Bitbucket Server APIs.2789 npmMIT