Mcp Server Bitbucket — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Mcp Server Bitbucket (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
<!-- mcp-name: io.github.JaviMaligno/bitbucket -->
MCP server for Bitbucket API operations. Works with Claude Code, Claude Desktop, Cursor, and any MCP-compatible client.
This repository contains both TypeScript and Python implementations:
| Version | Directory | Status | Installation |
|---|---|---|---|
| TypeScript | /typescript | ✅ Recommended (Smithery) | npm install -g mcp-server-bitbucket |
| Python | /python | ✅ Stable | pipx install mcp-server-bitbucket |
Note: The TypeScript version is used for Smithery deployments. Both versions provide identical functionality.
Use patched Node.js 22.23.4 or 24.22.1 for TypeScript, or Python 3.11+ for Python. See the security update for HTTP request bounds and reproducible image builds.
# Install globally
npm install -g mcp-server-bitbucket
# Or run directly with npx
npx mcp-server-bitbucket# Install with pipx
pipx install mcp-server-bitbucket
# Configure Claude Code
claude mcp add bitbucket -s user \
-e BITBUCKET_WORKSPACE=your-workspace \
-e [email protected] \
-e BITBUCKET_API_TOKEN=your-api-token \
-- mcp-server-bitbucket[Full Installation Guide](https://github.com/JaviMaligno/mcp-server-bitbucket/blob/main/docs/INSTALLATION.md) - Includes API token creation, permissions setup, and troubleshooting.
If you'd rather not run the server yourself, a hosted deployment is available on Fronteir AI.
| Variable | Required | Description |
|---|---|---|
BITBUCKET_WORKSPACE | ✅ | Bitbucket workspace slug |
BITBUCKET_EMAIL | ✅ (basic auth) | Account email for Basic Auth |
BITBUCKET_API_TOKEN | ✅ | Atlassian API token (Basic auth) |
BITBUCKET_OAUTH_TOKEN | Access token sent as Authorization: Bearer | |
BITBUCKET_AUTH_TYPE | Force auth mode: basic or bearer (auto-detected) | |
API_TIMEOUT | Request timeout in seconds (default: 30) | |
MAX_RETRIES | Max retry attempts for rate limiting (default: 3) |
Bitbucket Cloud has two credential families, and they do not share an auth scheme:
| Credential | Header | Configuration |
|---|---|---|
Atlassian API token (ATATT...), tied to a personal account | Authorization: Basic base64(email:token) | BITBUCKET_EMAIL + BITBUCKET_API_TOKEN |
Workspace / project / repository access token (ATCTT...), owned by the workspace | Authorization: Bearer <token> | BITBUCKET_OAUTH_TOKEN |
Access tokens return 401 with Basic auth, so the server picks the mode automatically:
BITBUCKET_AUTH_TYPE, when set, always wins.bearer is used when BITBUCKET_OAUTH_TOKEN is set, or when no BITBUCKET_EMAIL is configured.basic is used (the default for personal API tokens).Bearer example — a company-owned workspace access token with no personal account involved:
claude mcp add bitbucket -s user \
-e BITBUCKET_WORKSPACE=your-workspace \
-e BITBUCKET_OAUTH_TOKEN=your-workspace-access-token \
-- npx mcp-server-bitbucketThe stdio server runs on your machine with your own credential, so it needs no protection. A remote deployment is different: it holds one shared credential and serves whoever reaches it, so /mcp can be gated on a bearer token issued by an external authorization server (Microsoft Entra ID, Okta, Auth0…).
| Variable | Description |
|---|---|
MCP_OAUTH_ISSUER | Token issuer, e.g. https://login.microsoftonline.com/<tenant>/v2.0 |
MCP_OAUTH_AUDIENCE | Expected aud claim, e.g. api://bitbucket-mcp |
MCP_OAUTH_JWKS_URI | Signing keys (derived from the issuer when omitted) |
MCP_OAUTH_REQUIRED_SCOPE | Scope the token must carry, e.g. mcp.access |
MCP_PUBLIC_URL | Public URL of this server, advertised as the resource |
Protection is off unless both `MCP_OAUTH_ISSUER` and `MCP_OAUTH_AUDIENCE` are set, so existing deployments are unaffected. With them set, the server:
/mcp requests with 401 and a WWW-Authenticateheader pointing at /.well-known/oauth-protected-resource, which is what makes an MCP client start the OAuth flow;
iss, aud and expiry — and returns 403 insufficient_scope when a valid token lacks the required scope;
/health open, so platform probes keep working.Note what this does and does not do: it controls who may use the server. Calls still reach Bitbucket under the server's own credential, so it does not attribute actions to individual users.
# TypeScript version
claude mcp add bitbucket -s user \
-e BITBUCKET_WORKSPACE=your-workspace \
-e [email protected] \
-e BITBUCKET_API_TOKEN=your-api-token \
-- npx mcp-server-bitbucket
# Python version
claude mcp add bitbucket -s user \
-e BITBUCKET_WORKSPACE=your-workspace \
-e [email protected] \
-e BITBUCKET_API_TOKEN=your-api-token \
-- mcp-server-bitbucketAdd to ~/.cursor/mcp.json:
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": ["mcp-server-bitbucket"],
"env": {
"BITBUCKET_WORKSPACE": "your-workspace",
"BITBUCKET_EMAIL": "[email protected]",
"BITBUCKET_API_TOKEN": "your-api-token"
}
}
}
}| Tool | Description |
|---|---|
list_repositories | List and search repositories |
get_repository | Get repository details |
create_repository | Create a new repository |
delete_repository | Delete a repository |
update_repository | Update repo settings |
| Tool | Description |
|---|---|
list_pull_requests | List PRs |
get_pull_request | Get PR details |
create_pull_request | Create a new PR |
merge_pull_request | Merge a PR |
approve_pr | Approve a PR |
unapprove_pr | Remove approval |
request_changes_pr | Request changes |
decline_pr | Decline a PR |
list_pr_comments | List comments |
add_pr_comment | Add comment |
get_pr_diff | Get the diff |
| Tool | Description |
|---|---|
list_pipelines | List recent runs |
get_pipeline | Get status |
get_pipeline_logs | View logs |
trigger_pipeline | Trigger a run (supports custom pipelines and commit triggers) |
stop_pipeline | Stop pipeline |
list_pipeline_variables | List variables |
get_pipeline_variable | Get variable |
create_pipeline_variable | Create variable |
update_pipeline_variable | Update variable |
delete_pipeline_variable | Delete variable |
#### trigger_pipeline Parameters
| Parameter | Type | Description |
|---|---|---|
repo_slug | string | Repository slug (required) |
branch | string | Branch to run on (default: main). Mutually exclusive with commit |
commit | string | Commit hash to run on. Mutually exclusive with branch |
custom_pipeline | string | Name from custom: section in bitbucket-pipelines.yml |
variables | array | Variables as [{key, value, secured?}] |
Examples:
# Default pipeline on main
trigger_pipeline(repo_slug="my-repo")
# Custom pipeline
trigger_pipeline(repo_slug="my-repo", custom_pipeline="deploy-staging")
# Custom pipeline on specific commit with variables
trigger_pipeline(
repo_slug="my-repo",
commit="abc123def",
custom_pipeline="deploy-prod",
variables=[
{"key": "ENV", "value": "production"},
{"key": "SECRET", "value": "xxx", "secured": True}
]
)See history queries, pagination and retry behavior.
| Tool | Description |
|---|---|
list_branches | List branches |
get_branch | Get branch details |
list_commits | Paginated history with revision include/exclude and path filters |
get_commit | Get commit details |
compare_commits | Paginated changed-file statistics from base to head |
get_commit_diff | Raw diff, optionally by file, with explicit chunk continuation |
get_merge_base | Best common ancestor of two revisions |
get_file_history | Paginated file history with paths reported across renames |
get_commit_statuses | Get build statuses |
create_commit_status | Report CI status |
list_tags | Paginated tags with filtering and configurable sorting |
get_tag | Resolve an exact tag to its full target commit hash |
create_tag | Create a tag |
delete_tag | Delete a tag |
list_environments, get_environment, list_deployment_historylist_webhooks, create_webhook, get_webhook, delete_webhooklist_branch_restrictions, create_branch_restriction, delete_branch_restrictionget_file_content, list_directorylist_projects, get_projectReusable workflow templates:
| Prompt | Description |
|---|---|
code_review | Comprehensive PR code review |
release_notes | Generate changelog between versions |
pipeline_debug | Debug failed CI/CD pipelines |
repo_summary | Complete repository status overview |
Browsable workspace data:
| Resource URI | Description |
|---|---|
bitbucket://repositories | List all repos |
bitbucket://repositories/{repo} | Repository details |
bitbucket://repositories/{repo}/branches | Branch list |
bitbucket://repositories/{repo}/pull-requests | Open PRs |
bitbucket://projects | List all projects |
cd typescript
npm install
npm run build
npm run dev # Watch modecd python
uv sync
uv run python -m src.serverIf your team is running this against a company Bitbucket, I'd like to know. It decides what gets built next, and issues that come from a real deployment get looked at first.
Two kinds of work I take on around this:
this one, against your own API.
handling, self-hosting the transport.
Open an issue, or write to [email protected].
Built and maintained by Javier Aguilar — AI engineer working on agent systems and MCP integrations. There's a write-up of how and why this server was built here.
MIT
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.