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.
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.
- 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 `rustls` only, with no OpenSSL in the build
A Bitbucket API token created in your Atlassian account, with the scopes you need — the README names `repository:read` and `pullrequest:read` as examples. Two environment variables carry it: `BITBUCKET_API_USERNAME`, which is your Atlassian email, and `BITBUCKET_API_TOKEN`. Run the container with `docker run -e BITBUCKET_API_USERNAME=... -e BITBUCKET_API_TOKEN=... -p 8080:8080 ghcr.io/ibrahimogod/bitbucket-mcp:latest`, or build from source with `cargo build --release` and run the `bitbucket_stdio` binary.
One command plus a key — docker run -e BITBUCKET_API_USERNAME=<your_atlassian_email> -e BITBUCKET_API_TOKEN=<your_api_token> -p 8080:8080 ghcr.io/ibrahimogod/bitbucket-mcp:latest, then supply credentials