bitbucket-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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_prA | Fetch a Bitbucket pull request's metadata (title, state, author, branches, description, URL). |
| list_prsA | List pull requests in a Bitbucket repository. Filter by state, author UUID, or branch. Returns up to |
| get_pr_diffA | Fetch the unified diff for a pull request. For a large PR, start with |
| list_pr_commentsA | List all comments on a pull request, including general and inline (file+line) comments. Returns comments sorted oldest-first. |
| list_pipelinesA | Find Bitbucket Pipelines builds and their per-step pass/fail state. Scope it with |
| get_pipeline_step_logA | Fetch the log output of a pipeline step. |
| get_build_statusA | Answer "is this commit green?" in one call, using Bitbucket's commit build statuses (Pipelines results plus anything else that posts a status). Pass |
| add_pr_commentA | Post a general comment on a pull request (not tied to a specific file or line). For inline file/line comments, use |
| reply_to_pr_commentA | Reply to an existing PR comment, creating a threaded reply. For inline comments, the path and line are inherited from the parent — do not use |
| update_prA | Update a pull request's title, description (the PR Overview), and/or reviewers. Pass any combination — fields you omit are left unchanged. The description is interpreted as Markdown. |
| set_pr_draft_stateA | Mark a pull request as draft or ready for review. Pass |
| resolve_pr_commentA | Mark a PR comment as resolved or unresolved. Defaults to resolved=true. Use |
| create_prA | Open a new pull request. |
| add_pr_inline_commentA | Post a comment on a specific file and line within a pull request's diff. Use |
| run_pipelineA | Start a Bitbucket pipeline — a re-run of a branch's build, or a definition from the |
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 15 tools
Every tool targets a distinct action and resource (e.g., general vs. inline vs. threaded replies for PR comments, pipeline listing vs. step logs vs. build status). Descriptions explicitly cross-reference related tools to prevent misselection, such as clarifying when to use list_pipelines over get_build_status.
All tool names follow a consistent verb_noun snake_case convention (e.g., get_pr, list_prs, add_pr_comment, run_pipeline). The verbs are clear and reused predictably across resource types, and pluralization follows natural language without breaking the pattern.
With 15 tools, the server covers a broad but focused domain—pull requests and pipelines. Each tool provides a distinct capability, and the count sits at the upper boundary of the optimal 3–15 range without feeling bloated or sparse.
The surface covers the full PR lifecycle (create, read, update, draft state, diff, comments) and pipeline operations (list, logs, run, build status). There are no obvious dead ends; even edge cases like large diffs and pipeline fallback behavior are addressed with dedicated parameters.