bitbucket-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BITBUCKET_EMAIL | Yes | Atlassian account email used for Basic Auth. | |
| BITBUCKET_TOKEN | Yes | Bitbucket API token. Never an app password. | |
| BITBUCKET_WORKSPACE | No | Process-level override for workspace resolution. Takes precedence over the active profile's default, but not over an explicit workspace tool argument. | |
| BITBUCKET_PROFILES_PATH | No | Overrides where profiles.json lives. Default: ${XDG_CONFIG_HOME:-~/.config}/bitbucket-mcp/profiles.json. |
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_workspacesA | Lists every Bitbucket workspace the authenticated credentials can access, fully paginated. Takes no arguments. |
| list_profilesA | Lists every configured local profile and its defaults. Never contacts Bitbucket. |
| get_active_profileA | Returns the currently active profile's name and resolved defaults, if any. |
| set_active_profileA | Switches the active profile to an existing profile. Purely local — never calls Bitbucket. |
| set_default_workspaceA | Persists a default workspace on the active (or explicitly named) profile. Purely local — never calls Bitbucket. |
| clear_default_workspaceA | Removes the persisted default workspace from the active (or explicitly named) profile. Idempotent. Purely local — never calls Bitbucket. |
| list_repositoriesA | Lists every repository in a workspace, fully paginated. Resolves |
| get_repositoryA | Returns details for a specific repository. Requires |
| list_branchesA | Lists every branch in a repository, fully paginated. Resolves |
| get_branchA | Returns details for a specific branch. Requires |
| list_pull_requestsA | Lists pull requests in a repository, fully paginated. Requires an explicit |
| get_pull_requestA | Returns full metadata for a single pull request. Requires |
| get_pr_commitsB | Lists every commit belonging to a pull request, fully paginated. Requires an explicit |
| get_pr_diffA | Returns the unified diff for a pull request as plain text, capped by default at 100,000 characters ( |
| list_pr_commentsA | Lists every comment (inline and general) on a pull request, fully paginated. Requires an explicit |
| create_pr_commentA | Posts a new comment on a pull request. Requires non-empty |
| create_pull_requestA | Opens a new pull request. Requires |
| update_pull_requestA | Updates a pull request's title, description, destination branch, and/or reviewers. Does NOT support merge, approve, or decline — passing a |
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 18 tools
Each tool targets a distinct resource and action: local profile operations are clearly separated from Bitbucket API operations, and list/get/create/update verbs are consistently paired with specific objects like workspaces, repositories, branches, pull requests, and comments. There is no meaningful overlap or ambiguous boundary between tools.
Tool names mostly follow a consistent list_/get_/create_/update_/set_/clear_ verb_noun pattern, which is predictable and readable. The main deviation is mixing 'pr' and 'pull_request' across related tools (e.g. get_pr_commits vs get_pull_request), which slightly weakens consistency.
At 18 tools, the set is slightly above the ideal 3–15 range, but each tool addresses a distinct need across workspaces, repositories, branches, pull requests, comments, and local profile configuration. The count feels slightly heavy but not bloated.
The read side is well covered, and pull request creation plus commenting are supported, but notable lifecycle operations are missing: merge/approve/decline for pull requests, repository/branch write operations, and profile creation/deletion. These gaps prevent full CRUD/lifecycle coverage of the apparent Bitbucket domain.