LABSCO SUMMARY
Built to be dropped into a pipeline.
The design choices point at automation rather than desktop use: stateless, a single static binary, rustls instead of OpenSSL, and a published image tagged per release. It is write-capable — merging and commenting are in scope — so the token's scopes are what actually bound it, and a read-only token is the way to keep an assistant to reporting.
What it is
A stateless MCP server over the Bitbucket Cloud API, built in Rust. It exposes the major Bitbucket surfaces to an assistant or an automation, and is packaged as a prebuilt container so it can drop into CI as easily as into an editor.
What you get
- Repositories, workspaces, branches, tags and commits, listed and read
- Pull request workflows end to end — create, update, approve, decline, merge, comment and manage tasks
- Issues, plus projects, snippets, downloads and webhooks
- Pipelines and deployments, so build state is readable alongside the code
- A prebuilt image on GHCR —
ghcr.io/ibrahimogod/bitbucket-mcp:latest— with VS Code and Cursor configs that launch it through Docker - TLS through
rustlsonly, with no OpenSSL in the build
Requirements
- A Bitbucket API token created in your Atlassian account, with the scopes you need, such as
repository:readandpullrequest:read. - Two environment variables carry it:
BITBUCKET_API_USERNAME, which is your Atlassian email, andBITBUCKET_API_TOKEN. - Your client starts the container itself with
docker run -iand those two variables, as the VS Code and Cursor configurations show — the image runs the stdio binary, so it needs-iand listens on no port. - Or build from source with
cargo build --releaseand run thebitbucket_stdiobinary.
Setup effort
Run a container — pull the image and point your client at it
USE CASES
Reviewing pull request activity across repositories
Ask what is open and who is waiting, without opening Bitbucket.
Automating a merge step in CI
Run the container in the pipeline and drive the pull request workflow from an agent.
Checking why a pipeline failed
Read pipeline and deployment state next to the commits that triggered them.
Keeping an assistant read-only
Issue a token with read scopes only, so the same server can report but not merge.
BEFORE YOU INSTALL
What to know first
Requires
- docker on PATH
- BITBUCKET_API_TOKEN in your environment
- BITBUCKET_API_USERNAME in your environment
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
MCP Clients
VS Code
{
"servers": {
"bitbucket-mcp-docker": {
"command": "docker",
"args": [
"run",
"-i",
"-e",
"BITBUCKET_API_USERNAME",
"-e",
"BITBUCKET_API_TOKEN",
"-e",
"RUST_BACKTRACE",
"ghcr.io/ibrahimogod/bitbucket-mcp:latest"
],
"env": {
"BITBUCKET_API_USERNAME": "<YOUR_BITBUCKET_API_USERNAME>",
"BITBUCKET_API_TOKEN": "<YOUR_BITBUCKET_API_TOKEN>",
"RUST_BACKTRACE": "1"
}
}
}
}Cursor
{
"mcpServers": {
"bitbucket-mcp-docker": {
"command": "docker",
"args": [
"run",
"-i",
"-e",
"BITBUCKET_API_USERNAME",
"-e",
"BITBUCKET_API_TOKEN",
"-e",
"RUST_BACKTRACE",
"ghcr.io/ibrahimogod/bitbucket-mcp:latest"
],
"env": {
"BITBUCKET_API_USERNAME": "<YOUR_BITBUCKET_API_USERNAME>",
"BITBUCKET_API_TOKEN": "<YOUR_BITBUCKET_API_TOKEN>",
"RUST_BACKTRACE": "1"
}
}
}
}