About bitbucket-mcp-server
bitbucket-mcp-server is an MCP server for Bitbucket Cloud, aimed at teams that want AI-assisted pull request review alongside common PR operations. Its provider-agnostic interfaces separate review and business logic from SCM, LLM, cache, and token-storage implementations.
Key features
- 01AI pull request analysis
- 02Pull request listing and retrieval
- 03Create and edit pull requests
- 04Diff, file, and comment access
- 05OAuth 2.0 and bearer authentication
- 06stdio and Streamable HTTP transports
Use cases
- 01Analyze a Bitbucket pull request
- 02Inspect changed files and diffs
- 03Create or update a pull request
- 04Add comments to a pull request
MCP support
Exposes Bitbucket Cloud pull request operations and AI review as MCP tools. It supports stdio and Streamable HTTP, with tool discovery handled by a registry.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
npx -y @droplinkperformance/bitbucket-mcp-serverBITBUCKET_ACCESS_TOKENSecretBitbucket API token (ATATT), app password, or OAuth access tokenBITBUCKET_EMAILAtlassian account email (required with API tokens)BITBUCKET_DEFAULT_WORKSPACEDefault Bitbucket workspace when a tool omits workspaceLLM_PROVIDERLLM backend for analyze_pull_request (openai, anthropic, gemini, bedrock)OPENAI_API_KEYSecretOpenAI API key when LLM_PROVIDER is openaiLocal servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.
Tools
Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.
Details
From the project README@droplinkperformance/bitbucket-mcp-server
Provider-agnostic, AI-review-first Model Context Protocol (MCP) server for Bitbucket Cloud.
The primary value of this server is AI-powered code review and pull request analysis, not CRUD against the Bitbucket API. Every major dependency (SCM access, cache, token storage, rate limiting, LLM, events) is hidden behind a provider-agnostic interface so the same business logic can later target GitHub / GitLab / Azure DevOps and OpenAI / Anthropic / Gemini / Bedrock without changes to use-cases, agents, or domain contracts.
Status: Phase 1. See Roadmap.
Features (Phase 1)
- Dual transports: stdio (Cursor / Claude Desktop) and Streamable HTTP (Node
http, for remote/production). - Auto-discovered tools via a
ToolRegistry— no manual registration. - Explicit
BitbucketContext(workspace+ optionalrepository) on every tool — multi-workspace ready. - Resilient
BitbucketClient: auth injection, auto-pagination, retry/backoff, rate-limit handling, caching, secret masking. - Two auth strategies: OAuth 2.0 (Authorization Code, with rotating refresh-token persistence) and Bearer token.
- AI code review (
analyze_pull_request) backed by aCodeReviewAgentthat chunks large PRs and returns a standardReviewResult. - Pluggable LLM provider (OpenAI / Anthropic / Gemini / Bedrock), cache (memory / Redis), and token store (file / memory / Redis).
Tools
| Tool | Description |
|---|---|
get_current_user | Authenticated user. |
list_pull_requests | List PRs (filter by state/query). |
get_pull_request | Fetch a PR by id. |
create_pull_request | Open a PR. |
update_pull_request | Edit an open PR title and/or description. |
get_pull_request_diff | Raw unified diff. |
get_pull_request_files | Changed files + line stats. |
get_pull_request_comments | PR comments. |
comment_pull_request | Add a (optionally inline) comment. |
analyze_pull_request | AI review returning a standard ReviewResult. |
All tool inputs accept workspace (optional if BITBUCKET_DEFAULT_WORKSPACE is set) and, where applicable, repository.
Architecture
src/
index.ts entry: chooses transport
container.ts composition root (the only place wiring concretes)
mcp/ McpServer + ToolRegistry (auto-discovery) + transports
tools/ thin MCP adapters (*.tool.ts) -> call exactly one use-case
application/ use-cases (CQRS-ish: command|query) with Input/Output DTOs
agents/ autonomous workflows implementing Agent<TInput,TOutput>
domain/ provider-agnostic types, repository contracts, ReviewResult
repositories/bitbucket/ Bitbucket implementations of the contracts
clients/bitbucket/ resilient REST client
auth/ AuthProvider (+ token/oauth) and TokenStore implementations
cache/ CacheProvider (+ memory/redis)
ratelimit/ RateLimitStrategy (+ bitbucket)
llm/ LlmProvider (+ openai/anthropic/gemini/bedrock)
events/ EventBus (+ in-memory)
services/ reusable services (masking, chunking)
telemetry/ OpenTelemetry bootstrap + metrics
infrastructure/ config, logger, http, attachments
shared/ errors, result envelope, http-status, BitbucketContext
Flow: tool -> use-case -> (agent | repository contract) -> repositories/bitbucket -> BitbucketClient. Agents may also use the LlmProvider and EventBus. Tools never contain business logic.
Requirements
- Node.js 23+
Install
Published as @droplinkperformance/bitbucket-mcp-server.
npx -y @droplinkperformance/bitbucket-mcp-server
From source:
npm install
npm run build
Release
Merges to main run .github/workflows/release.yml: tests, build, then semantic-release. Version and npm publish happen only when the merge includes Conventional Commits:
| Commit | Bump |
|---|---|
fix: | patch |
feat: | minor |
BREAKING CHANGE / feat!: | major |
Other messages skip publish. The GitHub secret NPM_TOKEN (npm Automation token for the droplinkperformance org) is required.
After a successful npm release, the same workflow waits until that version is visible on the npm registry, then publishes metadata to the MCP Registry as io.github.droplinkperformance/bitbucket-mcp-server (OIDC, no extra secret). To republish MCP metadata for the current package.json version without cutting a new release, run the workflow manually with Publish mcp only. github.com/mcp syncs from that registry; if the server does not appear, email [email protected].
To stay on 0.x for the first release, tag the current commit (git tag v0.1.0 && git push origin v0.1.0) before the first conventional merge; otherwise semantic-release starts at 1.0.0.
Configuration
Copy .env.example to .env and fill in values. Load it with Node's built-in flag:
node --env-file=.env dist/index.js
Key variables:
| Variable | Default | Notes |
|---|---|---|
MCP_TRANSPORT | stdio | stdio or http. |
HTTP_HOST / HTTP_PORT | 0.0.0.0 / 3000 | HTTP transport bind. |
BITBUCKET_DEFAULT_WORKSPACE | – | Fallback when a tool omits workspace. |
BITBUCKET_ACCESS_TOKEN | – | API token (ATATT…), app password, or OAuth access token |
BITBUCKET_EMAIL | – | Required with API tokens (ATATT…) — your Atlassian account email |
BITBUCKET_CLIENT_ID / BITBUCKET_CLIENT_SECRET | – | Required for OAuth (when no access token). |
BITBUCKET_REFRESH_TOKEN | – | Optional seed for headless OAuth. |
TOKEN_STORE | file | file | memory | redis. |
CACHE_PROVIDER | memory | memory | redis. |
LLM_PROVIDER | openai | openai | anthropic | gemini | bedrock. |
MAX_FILES_PER_CHUNK / MAX_DIFF_LINES_PER_CHUNK | 50 / 5000 | Large-PR chunking thresholds. |
OTEL_ENABLED | false | No-op metrics unless enabled. |
Authentication
Bearer (OAuth access token): set BITBUCKET_ACCESS_TOKEN only (non-ATATT tokens).
API token (recommended, ATATT…): set BITBUCKET_ACCESS_TOKEN and BITBUCKET_EMAIL (your Atlassian account email from Bitbucket → Personal settings → Email aliases). API tokens use HTTP Basic auth, not Bearer.
App password (legacy, until June 2026): set BITBUCKET_ACCESS_TOKEN and BITBUCKET_USERNAME (your Bitbucket username).
OAuth 2.0 (Authorization Code): set BITBUCKET_CLIENT_ID / BITBUCKET_CLIENT_SECRET. Tokens are persisted by the configured TOKEN_STORE; Bitbucket rotates refresh tokens, and the server persists the new one on every refresh. For headless boot, provide a previously obtained BITBUCKET_REFRESH_TOKEN.
Bitbucket OAuth endpoints used: authorize https://bitbucket.org/site/oauth2/authorize, token https://bitbucket.org/site/oauth2/access_token. The authorize URL can be built from OAuthProvider.buildAuthorizeUrl() and the returned ?code= exchanged via OAuthProvider.loginWithCode(code).
LLM provider
Set LLM_PROVIDER and the matching key:
LLM_PROVIDER=openai # OPENAI_API_KEY
LLM_PROVIDER=anthropic # ANTHROPIC_API_KEY
LLM_PROVIDER=gemini # GEMINI_API_KEY
LLM_PROVIDER=bedrock # AWS creds + BEDROCK_MODEL_ID (needs @aws-sdk/client-bedrock-runtime)
ioredis (Redis providers) and @aws-sdk/client-bedrock-runtime (Bedrock) are optional and loaded lazily — only needed when selected.
Running
stdio
MCP_TRANSPORT=stdio node --env-file=.env dist/index.js
Streamable HTTP
MCP_TRANSPORT=http HTTP_PORT=3000 node --env-file=.env dist/index.js
# health: GET http://localhost:3000/health
# endpoint: POST http://localhost:3000/mcp
MCP Inspector
npx @modelcontextprotocol/inspector node dist/index.js
Cursor
~/.cursor/mcp.json (or project .cursor/mcp.json):
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": ["-y", "@droplinkperformance/bitbucket-mcp-server"],
"env": {
"MCP_TRANSPORT": "stdio",
"BITBUCKET_ACCESS_TOKEN": "ATATT-your-api-token",
"BITBUCKET_EMAIL": "[email protected]",
"BITBUCKET_DEFAULT_WORKSPACE": "your-workspace",
"LLM_PROVIDER": "openai",
"OPENAI_API_KEY": "sk-..."
}
}
}
}
Claude Desktop
claude_desktop_config.json:
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": ["-y", "@droplinkperformance/bitbucket-mcp-server"],
"env": {
"BITBUCKET_ACCESS_TOKEN": "your-token",
"BITBUCKET_DEFAULT_WORKSPACE": "your-workspace",
"LLM_PROVIDER": "anthropic",
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}
Development
npm run dev # tsx watch (stdio)
npm run typecheck
npm run lint
npm test
npm run test:coverage
Roadmap
- Phase 1 (this release): auth, abstractions,
BitbucketClient, tool auto-discovery, PR tools,analyze_pull_request. - Phase 2: Pipelines + full-text paginated logs,
pipeline-investigatoragent,auto_review_pull_request(dry-run / publish inline comments). - Phase 3: Remaining CRUD — repositories, commits, branches, tags, issues, workspaces, members, search.
- Phase 4:
analyze_dotnet_pull_request(dotnet-review agent), advanced agents, automation workflows. - Phase 5: Docker, Compose, Helm, production deploy guide.
License
MIT
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.