bitbucket-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BITBUCKET_URL | Yes | Your Bitbucket Server URL (e.g., https://bitbucket.example.com) | |
| BITBUCKET_TOKEN | Yes | Personal access token with read permissions |
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 |
|---|---|
| get_user_profileA | Get Bitbucket Server user profile by username |
| get_all_usersA | Retrieve a page of users, optionally filtered by search term |
| list_projectsA | List projects visible to the authenticated user. Can filter by name or permission. |
| list_repositoriesB | List all repositories in a Bitbucket Server project |
| get_inbox_pull_requestsA | Returns pull requests in the authenticated user's inbox where they are assigned as a reviewer. |
| get_pull_requestA | Get full details for a pull request including title, description, author, state, branches, reviewers, and participants. |
| get_pull_request_changesA | Get list of all changed files in a pull request with file-level metadata (paths, change types like ADD/MODIFY/DELETE). |
| get_pull_request_diffB | Get diff for a pull request. Omit path for full PR diff, or specify a file path for a specific file. Supports text and JSON formats. |
| get_pull_request_file_diffA | Get structured line-by-line diff for a specific file in a pull request. Returns JSON with hunks, segments, and exact line numbers. |
| get_pull_request_activitiesC | Get activity on a pull request including comments, approvals, merges, reviews, and updates. Can filter by activity types. |
| get_pull_request_commitsB | Get the commits for a pull request. |
| list_pull_requestsA | List pull requests for a repository. Can filter by state, direction, and branch. |
| get_repositoryB | Get details of a specific repository. |
| list_branchesB | List branches for a repository. |
| browse_filesC | Browse files/directories in a repository at a given path and ref. |
| get_file_contentC | Get the raw content of a file in a repository. |
| list_commitsC | List commits for a repository, optionally filtered by branch/tag/commit. |
| get_commitA | Get details of a specific commit. |
| get_commit_diffA | Get the diff for a specific commit. |
| list_tagsC | List tags for a repository. |
| get_default_branchB | Get the default branch of a repository. |
| get_pull_request_merge_statusC | Check if a pull request can be merged (merge preconditions). |
| get_pull_request_tasksB | Get tasks/blockers on a pull request. |
| search_codeB | Search for code across repositories. |
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 24 tools
Most tools clearly target distinct resources or specific aspects (e.g., PR activities vs. commits). The only real ambiguity is between get_pull_request_diff and get_pull_request_file_diff, which both involve diffs but with different output structures, so an agent could be unsure which to use.
The naming pattern is largely consistent, using get_ for single items and list_ for collections. However, get_inbox_pull_requests and get_all_users are list operations that use get_ instead of list_, which is a minor deviation from the dominant verb convention.
With 24 tools, this server is on the heavy side, fitting the borderline range of 16-25. The count is driven by 10 pull-request-related tools, which feel numerous even though each has a distinct purpose. A more consolidated set would be more appropriate.
The server is entirely read-only, lacking any create, update, delete, merge, or comment capabilities for repositories or pull requests. This is a significant gap for a Bitbucket integration, preventing agents from completing common lifecycle workflows like approving or merging a PR.