bitbucket-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port (only if TRANSPORT=http) | 3000 |
| TRANSPORT | No | Transport mode: stdio or http | stdio |
| BITBUCKET_USERNAME | Yes | Email or username of Bitbucket | |
| BITBUCKET_API_TOKEN | Yes | API Token of Bitbucket | |
| BITBUCKET_WORKSPACE | No | Default workspace (avoids passing it on each call) | |
| BITBUCKET_ENABLE_DANGEROUS | No | Enables destructive operations (merge, decline) | false |
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_pull_requestsC | List pull requests for a repository |
| get_pull_requestC | Get details of a specific pull request |
| get_pull_request_diffC | Get the diff of a pull request |
| get_pull_request_commentsC | List comments on a pull request |
| get_pull_request_activityC | Get the activity log of a pull request |
| search_workspace_membersA | Search for workspace members by display name. Useful for finding reviewer UUIDs. |
| create_pull_requestC | Create a new pull request |
| update_pull_requestC | Update an existing pull request (title, description, reviewers) |
| approve_pull_requestC | Approve a pull request |
| unapprove_pull_requestC | Remove approval from a pull request |
| request_changesC | Request changes on a pull request |
| add_pull_request_commentB | Add a comment to a pull request (general, inline on a file/line, or reply to existing comment) |
| merge_pull_requestA | Merge a pull request (requires BITBUCKET_ENABLE_DANGEROUS=true) |
| decline_pull_requestA | Decline a pull request (requires BITBUCKET_ENABLE_DANGEROUS=true) |
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 14 tools
Read tools (list, get, diff, comments, activity) and write tools (create, update, approve, unapprove, request_changes, comment, merge, decline) each target a distinct action on a pull request. Slight potential for confusion between get_pull_request_activity and get_pull_request_comments (activity logs often include comments), and between approve_pull_request and request_changes, but descriptions clarify the boundaries.
Every tool follows a consistent snake_case verb_noun pattern (list_pull_requests, get_pull_request_diff, add_pull_request_comment, merge_pull_request). Even the odd-one-out search_workspace_members fits the same convention.
14 tools is well within the ideal range and each maps to a meaningful step in the PR review/merge workflow. No redundant or filler tools are present.
The pull request lifecycle is thoroughly covered: discovery, inspection, creation, updates, review states (approve/unapprove/request changes), commenting, and merge/decline. Minor gaps remain around repository/branch discovery (no list_repositories or branch tools), which an agent may need to locate a repo before working with its PRs.