bitbucket-mcp-server
Provides tools for managing Bitbucket Cloud repositories, branches, pull requests, and deployments.
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"
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
A community Model Context Protocol server for Bitbucket Cloud. Gives AI agents (Copilot, Claude, etc.) safe, typed access to repositories, branches, pull requests, and deployments.
Quick start
# 1 — Install
npm ci
# 2 — Configure (copy and fill in your credentials)
cp .env.example .env
# 3 — Build
npm run build
# 4 — Run
node build/index.jsRelated MCP server: bitbucket-python-mcp
Features
Area | Tools |
Repositories |
|
Branches |
|
Pull Requests |
|
Deployments |
|
Configuration
Environment variables
Variable | Required | Default | Description |
| Yes* | — | API token (Bearer auth — recommended) |
| Yes* | — | Bitbucket account email (Basic auth — legacy) |
| Yes* | — | App Password (Basic auth — legacy) |
| Yes | — | Workspace slug |
| No |
| API base URL (override for testing) |
| No |
|
|
| No |
| HTTP server port (only when |
| No |
| HTTP server bind address |
| No |
|
|
| No |
|
|
* Authentication: set
BITBUCKET_API_TOKENor bothBITBUCKET_USERNAME+BITBUCKET_APP_PASSWORD. If both are provided, the API token takes priority.
MCP client configuration
Local (stdio — default)
Add this to your MCP client settings (VS Code, Claude Desktop, etc.):
{
"mcpServers": {
"bitbucket": {
"command": "node",
"args": ["/path/to/bitbucket-mcp-server/build/index.js"],
"env": {
"BITBUCKET_API_TOKEN": "your-api-token",
"BITBUCKET_WORKSPACE": "your-workspace"
},
"transportType": "stdio"
}
}
}Remote (HTTP — VPC service)
Deploy the server with MCP_TRANSPORT=http and point clients to the HTTP endpoint:
{
"mcpServers": {
"bitbucket": {
"url": "http://your-mcp-host:3000/mcp",
"transportType": "http"
}
}
}The HTTP server exposes:
Endpoint | Method | Purpose |
| GET | Health check (ALB/ECS probes) |
| POST | MCP JSON-RPC requests |
| GET | SSE stream for server-initiated messages |
| DELETE | Session termination |
Creating a Bitbucket App Password
Note: Bitbucket is deprecating App Passwords. Prefer API tokens (Repository or Workspace Access Tokens) for new setups.
Click Create app password
Select permissions:
Repositories: Read, Write, Admin
Pull requests: Read, Write
Account: Read
Copy the generated password
Development
Prerequisites
Node.js 24+
npm
Scripts
npm run build # Compile TypeScript → build/
npm run dev # Watch mode (tsc --watch)
npm run typecheck # Type-check without emitting
npm run lint # ESLint
npm run lint:fix # ESLint with auto-fix
npm run format # Prettier write
npm run format:check # Prettier check
npm run test # Vitest (single run)
npm run test:watch # Vitest (watch)
npm run test:coverage # Vitest with coverage
npm run inspector # MCP Inspector UIProject structure
src/
├── index.ts # Entry-point — McpServer setup & tool registration
├── config.ts # Zod-validated environment config (singleton)
├── logger.ts # Pino structured logger
├── httpClient.ts # Axios instance w/ retry, rate-limit logging
├── errors.ts # Custom error hierarchy
├── schemas.ts # Zod input schemas for every tool
├── types.ts # Bitbucket API response interfaces
├── *.test.ts # Unit tests (Vitest)
└── handlers/
├── repository.ts # Repos, branches, tags, commits, clone
├── branch.ts # Branch creation
├── pullRequest.ts # PR CRUD, review, merge, comments
└── deployment.ts # Deployment listing & detailsArchitecture highlights
MCP SDK 1.x high-level API — uses
McpServer.tool()with native Zod schema registration (no manual JSON-Schema).Zod everywhere — config validated at startup; tool inputs validated per-request.
Structured logging — pino with JSON output in production, pretty-print in development.
Automatic retries — axios-retry with exponential back-off for 429 / 5xx / network errors.
Rate-limit awareness — logs warnings when Bitbucket
X-RateLimit-Remainingdrops below threshold.Custom error classes —
ValidationError,BitbucketApiError,NotFoundError,ConfigError.No
any— fully typed handlers and schemas.
Docker
The Dockerfile defaults to HTTP mode (MCP_TRANSPORT=http) for containerised deployments.
# Build
docker build -t bitbucket-mcp-server .
# Run (HTTP mode — default in Docker)
docker run --env-file .env -p 3000:3000 bitbucket-mcp-serverOr using Docker Compose:
docker compose upThe Dockerfile uses a multi-stage build with node:24-slim, runs as a non-root user, and includes a HEALTHCHECK instruction.
Reliability
Concern | How it's handled |
Transient API failures | 3 retries w/ exponential back-off (1 s → 2 s → 4 s) |
Rate limiting | 429 responses are retried; |
Invalid input | Zod rejects bad input before any API call is made |
Missing config | Startup fails fast with a clear error listing all missing variables |
Graceful shutdown | SIGINT / SIGTERM handlers close the MCP connection cleanly |
Dual transport |
|
License
MIT
Available Tools
17 toolsadd_pull_request_commentB
Add a comment to a pull request
Inputs: content (required), repository (required), pull_request_id (required).
approve_pull_requestB
Approve a pull request
Inputs: repository (required), pull_request_id (required).
clone_repositoryB
Clone a repository using SSH (default) or HTTPS
Inputs: repository (required), branch, protocol, directory.
create_branchB
Create a new branch in a repository
Inputs: repository (required), branch_name (required), source_branch.
create_pull_requestB
Create a new pull request
Inputs: title (required), repository (required), source_branch (required), reviewers, +2 more.
decline_pull_requestC
Decline a pull request
Inputs: repository (required), pull_request_id (required), reason.
get_branch_commitsA
Get commit history and details for a specific branch
Inputs: branch (required), repository (required), page, pagelen.
get_deploymentA
Get details of a specific deployment
Inputs: repository (required), deployment_uuid (required).
get_pull_requestC
Get details of a specific pull request
Inputs: repository (required), pull_request_id (required).
get_pull_request_commentsB
Get all comments from a pull request
Inputs: repository (required), pull_request_id (required), page, pagelen.
list_branchesB
List branches in a repository
Inputs: repository (required).
list_deploymentsB
List deployments for a repository
Inputs: repository (required), page, pagelen, environment.
list_projectsB
List all projects in the workspace
Inputs: page, pagelen.
list_pull_requestsC
List pull requests in a repository
Inputs: repository (required), page, state.
list_repositoriesB
List repositories in the workspace
Inputs: page, pagelen, project.
list_tagsA
List tags in a repository
Inputs: repository (required), page, pagelen.
merge_pull_requestC
Merge a pull request
Inputs: repository (required), pull_request_id (required), merge_strategy, close_source_branch.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 17 tools
Every tool targets a distinct resource and action. The list tools (tags, repositories, projects, branches, PRs, deployments) are clearly separated by resource, and PR tools cover distinct lifecycle actions (create, get, approve, decline, merge, comments). No two tools appear to overlap.
All tool names follow a consistent verb_noun pattern using snake_case (list_*, get_*, create_*, clone_, approve_, decline_, merge_, add_). There is no mixing of casing or verb style, making the set predictable.
17 tools is slightly above the ideal 3-15 range, but the breadth is justified by covering repository browsing, branches, pull requests, and deployments. The count is reasonable and not bloated; every tool serves a distinct purpose.
The pull request lifecycle is well-covered (create, list, get, approve, decline, merge, comments), and browsing tools are solid. However, there are no repository creation/update/delete operations, and no update endpoint for pull requests or branch deletion. These are notable gaps for a Bitbucket server.
Maintenance
Related MCP Connectors
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
Related MCP Servers
- AlicenseCqualityCmaintenanceMCP server for integrating with Bitbucket Cloud and Server APIs, enabling AI assistants to interact with repositories, pull requests, pipelines, and more.5930 npm3MIT
- AlicenseAqualityDmaintenanceAn MCP server for BitBucket Cloud operations that enables AI agents to manage repositories, branches, pull requests, and search code.3251 PyPIMIT
- AlicenseNot gradedqualityCmaintenanceMCP server for Bitbucket Data Center that enables PR creation, review comment management, and rebasing workflows through natural language commands.MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for Bitbucket Cloud that exposes 35 tools covering repositories, pull requests, branching models, and pipelines, enabling AI clients to automate Bitbucket workflows.3MIT