Bitbucket MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BITBUCKET_BASE_URL | No | API base URL. Defaults to https://api.bitbucket.org/2.0. Override only for Bitbucket Server / Data Center. | https://api.bitbucket.org/2.0 |
| BITBUCKET_USERNAME | Yes | Your Atlassian account email (used as the Basic-auth username paired with the API token). | |
| BITBUCKET_WORKSPACE | Yes | Workspace slug from your Bitbucket URL. | |
| BITBUCKET_APP_PASSWORD | Yes | Your Atlassian API token from step 1. The variable is named APP_PASSWORD for backward compatibility. | |
| BITBUCKET_MCP_ALLOW_DESTRUCTIVE_TOOLS | No | Set to true, 1, yes, or on to expose delete_branch and delete_pr_comment. Off by default. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_repositoriesA | List all repositories in the configured workspace |
| list_branchesC | List branches in a repository |
| list_pull_requestsC | List pull requests for a repository |
| get_pull_requestA | Get full details of a specific pull request |
| create_pull_requestC | Create a new pull request |
| update_pull_requestB | Update the title, description, or reviewers of a pull request |
| merge_pull_requestB | Merge an open pull request. When merge_strategy is omitted, the repository's configured default for the PR's destination branch is used (falling back to merge_commit if none is set). |
| decline_pull_requestB | Decline (reject) an open pull request |
| add_pr_commentA | Post a Markdown comment on a pull request |
| get_diffA | Get the unified diff for a pull request (truncated to 8 KB) |
| list_pr_commentsB | List all comments on a pull request |
| get_pr_commentB | Get a specific comment on a pull request |
| update_pr_commentC | Update a comment on a pull request |
| resolve_pr_commentA | Resolve a comment thread on a pull request |
| reopen_pr_commentA | Reopen a resolved comment thread on a pull request |
| approve_pull_requestC | Approve a pull request |
| unapprove_pull_requestA | Remove your approval from a pull request |
| request_pr_changesC | Request changes on a pull request |
| list_pr_statusesB | List commit/build statuses for a pull request |
| list_default_reviewersA | List default reviewers for a repository (auto-added to new PRs) |
| get_default_reviewerB | Get a specific default reviewer |
| add_default_reviewerB | Add a user as default reviewer for the repository |
| remove_default_reviewerB | Remove a user from default reviewers |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Each tool targets a distinct resource/action: pull request lifecycle, comments, approvals, statuses, and default reviewers are all cleanly separated. Even closely related actions like approve, request changes, and decline are clearly differentiated by name and description.
The set overwhelmingly follows a verb_noun snake_case pattern, which makes it predictable. The main inconsistency is mixing 'pr' and 'pull_request' (e.g., list_pull_requests vs. list_pr_comments, get_pull_request vs. get_pr_comment), so it is not perfectly uniform.
At 23 tools, the server is in the heavy range. Each tool has a distinct purpose, but the granular review-state operations and default reviewer management could feel bloated compared to a leaner PR-focused server.
The server covers the core Bitbucket pull request workflow well: PR CRUD, merging/declining, comments, approvals, statuses, and default reviewers. Minor gaps exist, such as no single-repository fetch and no way to delete a PR comment, but these are unlikely to block common workflows.