Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 limit results sorted newest first.

get_pr_diffA

Fetch the unified diff for a pull request. For a large PR, start with stat_only: true to see which files changed and how big the diff is, then pass paths to fetch only the parts you need. Output is capped at max_bytes (default 100 KB) and the tail is dropped with a note when it overflows.

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 build_number (exact build), commit (SHA, short or full), branch, or pr_id — with none of those it uses the PR for the current branch. PR lookups do not require the repo to have a pull-requests: trigger: when no pipeline is attributable to the PR, this falls back to the most recent pipelines on the PR's source branch and says so in match and note. match: "none" means no pipeline ran at all — distinct from a fallback. Steps include their UUIDs, so this is where you get the arguments for get_pipeline_step_log.

get_pipeline_step_logA

Fetch the log output of a pipeline step. pipeline_uuid accepts either a pipeline UUID or a plain build number (e.g. 27419); UUIDs work with or without curly braces. Omit step_uuid to get the first failed step's log (or the last step when everything passed). Use tail_lines when you only need the end of the log — that is where failures are. Output is capped at max_bytes (default 100 KB), keeping the end of the log. If you only need whether a step passed, use list_pipelines instead — it returns step state without any log.

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 commit (a SHA) or pr_id; with neither, it uses the current checkout's HEAD. verdict is FAILED / INPROGRESS / STOPPED / SUCCESSFUL / NO_STATUSES. NO_STATUSES means nothing posted a status — check list_pipelines before concluding a build did not run.

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 add_pr_inline_comment.

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 add_pr_inline_comment to reply, since that posts a sibling comment instead of a threaded reply.

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. reviewers replaces the full reviewer list with the given Bitbucket account UUIDs (including the curly braces); pass an empty array to clear all reviewers.

set_pr_draft_stateA

Mark a pull request as draft or ready for review. Pass draft: true to convert to draft, or draft: false to mark ready.

resolve_pr_commentA

Mark a PR comment as resolved or unresolved. Defaults to resolved=true. Use list_pr_comments to see current resolution state.

create_prA

Open a new pull request. source_branch defaults to the current git branch when run from inside a checkout. destination_branch defaults to the repository's configured main branch on Bitbucket. description is interpreted as Markdown. reviewers is a list of Bitbucket account UUIDs (including the curly braces).

add_pr_inline_commentA

Post a comment on a specific file and line within a pull request's diff. Use get_pr_diff first if you need to confirm line numbers are present in the diff. For general PR comments, use add_pr_comment.

run_pipelineA

Start a Bitbucket pipeline — a re-run of a branch's build, or a definition from the custom: section of bitbucket-pipelines.yml. branch defaults to the current git branch; commit pins the build to a specific SHA instead of the branch tip. Consumes build minutes and can deploy, so confirm with the user before running a custom pipeline you did not pick out together. Requires the pipeline:write OAuth scope (re-run bitbucket-mcp setup if the server was set up before that scope existed).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 15 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues