Bitbucket MCP Server
The Bitbucket MCP Server allows you to interact with Bitbucket Cloud and Server/Data Center pull requests via the Model Context Protocol (MCP). It is read-only by default; write tools must be explicitly enabled.
Retrieve Pull Request Metadata (get_pull_request): Fetch details such as description, state, author, reviewers, source/destination branches, timestamps, and links.
Retrieve Pull Request Diffs (get_pull_request_diff): Get raw diffs and structured changed file data, with support for:
Filtering out generated or unwanted files using configurable glob patterns
Capping large diffs at a configurable byte limit without breaking UTF-8 characters
Combining per-request ignore patterns with globally configured ones
Add Pull Request Comments (add_pull_request_comment, requires BITBUCKET_ENABLE_WRITE_TOOLS=true): Create comments on pull requests, including:
General comments on the overall pull request
File-level comments targeting a specific file
Inline comments on specific lines in the diff, with control over which side (
old/new) the comment appears on
Authentication & Security: Supports bearer tokens (recommended for Server/Data Center PATs) and basic authentication (for Cloud API tokens/app passwords). Credentials are handled in memory, sent only to the configured BITBUCKET_URL, and redacted from error logs.
Note: The server does not support approving, merging, or other high-impact PR modifications.
Provides tools for retrieving pull request metadata, diffs, and adding comments on Bitbucket Cloud and Bitbucket Server/Data Center.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Bitbucket MCP Servershow me the diff for PR 7 in myworkspace/myrepo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Bitbucket MCP Server
A production-focused Model Context Protocol server for retrieving pull request metadata and diffs from Bitbucket Cloud and Bitbucket Server/Data Center, with opt-in pull request comments.
Features
Supports Bitbucket Cloud and self-hosted Bitbucket Server/Data Center.
Exposes focused tools for pull request metadata, diffs, review discussion, and general or inline comments.
Supports bearer tokens and basic authentication.
Returns raw diffs plus structured changed-file data when Bitbucket provides it.
Excludes generated files, folders, or file types through configurable glob patterns.
Caps large diffs without breaking UTF-8 characters.
Uses stdio without writing protocol-breaking logs to stdout.
Keeps comment creation disabled by default and does not approve, merge, or otherwise modify pull requests.
Related MCP server: Atlassian Bitbucket MCP Server
Quick start
Requires a supported Node.js LTS release (Node.js 22 or newer).
git clone https://github.com/inceon/bitbucket-mcp.git
cd bitbucket-mcp
npm install
npm run build
cp .env.example .envSet BITBUCKET_URL and BITBUCKET_TOKEN in your MCP client configuration, then launch the compiled server with node dist/index.js. The server intentionally does not load .env files itself; MCP clients should pass environment variables directly.
Authentication
Bearer authentication is the default and is recommended for Bitbucket Server/Data Center personal access tokens:
BITBUCKET_URL=https://bitbucket.example.com/bitbucket
BITBUCKET_TOKEN=your-personal-access-token
BITBUCKET_AUTH_TYPE=bearerFor Bitbucket Cloud API tokens or app passwords that require basic authentication:
BITBUCKET_URL=https://api.bitbucket.org
BITBUCKET_TOKEN=your-api-token-or-app-password
BITBUCKET_AUTH_TYPE=basic
BITBUCKET_USERNAME=your-bitbucket-usernameGrant the credential only the permissions needed for the tools you enable. Comment creation requires permission to create pull request comments. Never commit credentials or put real tokens in issue reports.
Environment variables
Variable | Required | Default | Description |
| Yes | - | Bitbucket base URL, such as |
| Yes | - | API token, app password, or personal access token |
| No |
|
|
| For basic auth | - | Username paired with the token for basic auth |
| No |
| Maximum UTF-8 byte size returned in |
| No |
| Maximum bytes read from an upstream raw diff before stopping |
| No |
| Maximum bytes read from any Bitbucket JSON response |
| No |
| Maximum pull request comments collected across pages |
| No |
| Maximum pull request comment pages followed |
| No |
| Maximum pull request commits collected across pages |
| No |
| Maximum pull request commit pages followed |
| No |
| Maximum structured changed-file entries collected across pages |
| No |
| Maximum structured changed-file pages followed |
| No |
| Deadline in milliseconds for each Bitbucket HTTP request |
| No | - | Comma-separated file globs excluded from every PR diff |
| No |
| Set to |
The server writes startup errors only to stderr and redacts configured credentials from Bitbucket HTTP error snippets.
MCP configuration
Claude Desktop configuration:
{
"mcpServers": {
"bitbucket": {
"command": "node",
"args": ["/absolute/path/to/my-bitbucket-mcp/dist/index.js"],
"env": {
"BITBUCKET_URL": "https://api.bitbucket.org",
"BITBUCKET_TOKEN": "your-token"
}
}
}
}Codex config.toml configuration:
[mcp_servers.bitbucket]
command = "node"
args = ["/absolute/path/to/my-bitbucket-mcp/dist/index.js"]
[mcp_servers.bitbucket.env]
BITBUCKET_URL = "https://api.bitbucket.org"
BITBUCKET_TOKEN = "your-token"Available tools
get_pull_request
Returns pull request metadata, including its description, state, author, reviewers, branches, timestamps, and links.
{
"name": "get_pull_request",
"arguments": {
"workspace": "my-workspace",
"repository": "my-repository",
"pull_request_id": 123
}
}get_pull_request_comments
Returns existing general and inline discussion as provider-native comment objects. Use it before posting a review finding to account for existing feedback. commentsStatus.complete is false with reason max_comments or max_pages when the configured retrieval bounds are reached.
get_pull_request_commits
Returns provider-native commits currently in the pull request. Use it to trace a finding to its originating commit or verify whether later work addresses it. commitsStatus.complete is false with reason max_commits or max_pages when the configured retrieval bounds are reached.
get_pull_request_diff
Returns a git-style review diff and structured changed files when available.
{
"name": "get_pull_request_diff",
"arguments": {
"workspace": "PROJECT_KEY",
"repository": "my-repository",
"pull_request_id": 123,
"ignore_patterns": ["dist/**", "**/*.generated.ts", "package-lock.json"],
"path": "src/service.ts",
"context": 5,
"ignore_whitespace": true,
"renames": true
}
}Diff output is available both as backward-compatible JSON text and as MCP structuredContent, with an advertised output schema. It includes:
provider,pull_request_id,rawDiff,rawDiffBytes, andrawDiffSource.rawDiffSourceisprovider_rawfor Cloud orserver_structuredfor a locally normalized Server/Data Center response.truncatedplustruncationReason:input_limitwhen the upstream Cloud read limit was reached,output_limitwhen the filtered result exceededBITBUCKET_MAX_DIFF_BYTES, orprovider_limitwhen Server/Data Center marked its structured diff as truncated.Optional compact
filesentries contain onlypath, normalizedstatus, andoldPathfor renames or copies. RequiredfilesStatusreports completeness;completeis false with reasonmax_files,max_pages, orunsupported, andreturnedreflects the filtered entries actually returned.Optional
ignoredmetadata when exclusions are active.
Complete result:
{
"provider": "cloud",
"pull_request_id": 123,
"rawDiff": "diff --git ...",
"rawDiffBytes": 128,
"rawDiffSource": "provider_raw",
"files": [],
"filesStatus": { "available": true, "complete": true, "returned": 0 },
"truncated": false
}Bounded partial result:
{
"provider": "cloud",
"pull_request_id": 123,
"rawDiff": "diff --git ...",
"rawDiffBytes": 200000,
"rawDiffSource": "provider_raw",
"files": [{ "path": "src/service.ts", "status": "modified" }],
"filesStatus": {
"available": true,
"complete": false,
"returned": 1,
"reason": "max_pages"
},
"truncated": true,
"truncationReason": "output_limit"
}Truncated rawDiff is a UTF-8-safe review prefix, not necessarily a complete line, hunk, or applicable patch.
Structured file pages are followed until complete or until a configured files/pages bound is reached, then normalized to compact review metadata rather than returning provider hashes, links, and duplicate path structures. An unavailable diffstat or changes endpoint is reported only after HTTP 404. Authorization, rate-limit, server, malformed-response, timeout, and transport failures fail the tool call rather than silently omitting metadata.
Cloud rawDiff preserves the provider's raw response. Server/Data Center uses the structured /diff response and normalizes its files, hunks, segments, and lines into git-style review text; this avoids version-specific failures from the separate .diff export route. rawDiffSource makes that distinction explicit.
path is supported for both providers and is the preferred way to review large pull requests file-by-file; returned files metadata is scoped to the same path. renames is Cloud-only. context maps to Cloud context and Server/Data Center contextLines. ignore_whitespace maps to Cloud ignore_whitespace and Server/Data Center whitespace=ignore-all. When absent, these controls do not alter provider defaults.
Patterns use repository-relative paths and support *, **, and ?. A pattern without /, such as package-lock.json or *.png, matches that filename anywhere. A trailing slash excludes a directory recursively. When exclusions are active, the response includes ignored.patterns, ignored.files, and ignored.rawDiffFiltered. A false rawDiffFiltered value means a Cloud provider returned a non-git diff format that could not be filtered safely; the response is preserved instead of silently dropping content.
add_pull_request_comment
Creates a general, file-level, or inline line comment on a pull request. This write operation is available only when BITBUCKET_ENABLE_WRITE_TOOLS=true is set in the MCP server environment.
General comment:
{
"name": "add_pull_request_comment",
"arguments": {
"workspace": "my-workspace",
"repository": "my-repository",
"pull_request_id": 123,
"comment": "The implementation looks good. Please add a regression test for the empty input case."
}
}Inline comment on an added line:
{
"name": "add_pull_request_comment",
"arguments": {
"workspace": "my-workspace",
"repository": "my-repository",
"pull_request_id": 123,
"comment": "Please handle an empty value here.",
"file_path": "src/service.ts",
"line": 42,
"line_type": "added"
}
}Use line_type values added, removed, or context. Added lines default to the new side, removed lines default to the old side, and context lines default to new; set line_side explicitly to place a context comment on old. Provide file_path without line fields for a file-level comment. For renamed files on Server/Data Center, source_file_path can identify the previous path.
The authenticated Bitbucket user becomes the comment author. Review the target workspace, repository, pull request ID, and comment text before approving the tool call in your MCP client.
create_pull_request
Creates a pull request from a pushed source_branch into destination_branch. This write operation requires BITBUCKET_ENABLE_WRITE_TOOLS=true. Supply a title and verify the workspace, repository, and target branch before approval; the authenticated Bitbucket user becomes the author.
Provider behavior
The URL host determines the provider. bitbucket.org and api.bitbucket.org use Bitbucket Cloud; all other hosts use Server/Data Center.
Cloud URLs are normalized to one /2.0 API prefix and use:
/repositories/{workspace}/{repository}/pullrequests/{id}/repositories/{workspace}/{repository}/pullrequests/{id}/diff/repositories/{workspace}/{repository}/pullrequests/{id}/diffstat/repositories/{workspace}/{repository}/pullrequests/{id}/comments(GET;POSTwhen enabled)/repositories/{workspace}/{repository}/pullrequests(POSTwhen enabled)/repositories/{workspace}/{repository}/pullrequests/{id}/commits(GET)
Server/Data Center URLs preserve a context path such as /bitbucket, normalize to one /rest/api/1.0 prefix, and use:
/projects/{project}/repos/{repository}/pull-requests/{id}/projects/{project}/repos/{repository}/pull-requests/{id}/diff(structured diff normalized to git-style review text)/projects/{project}/repos/{repository}/pull-requests/{id}/diff/{path}(path-scoped structured diff)/projects/{project}/repos/{repository}/pull-requests/{id}/changes/projects/{project}/repos/{repository}/pull-requests/{id}/comments(GET;POSTwhen enabled)/projects/{project}/repos/{repository}/pull-requests(POSTwhen enabled)/projects/{project}/repos/{repository}/pull-requests/{id}/commits(GET)
The optional diffstat or changes request reports filesStatus.reason: "unsupported" after HTTP 404. Other HTTP, timeout, transport, and parsing failures fail the tool call so incomplete metadata is not mistaken for a complete response.
Atlassian Rovo MCP
Atlassian documents a Cloud-only bitbucketPullRequest.diff action, but does not publish its argument schema, output shape, pagination, filtering, or truncation contract. This server therefore keeps direct Bitbucket APIs authoritative. A Rovo adapter should be added only after validating a live tools/list schema and controlled diff response; it must remain explicitly configured and cannot replace Server/Data Center support. See Atlassian's supported-tools page.
Roadmap
Planned areas for future releases include:
Add retry handling and clearer rate-limit diagnostics.
Provide normalized pull request output while retaining access to provider-specific fields.
Add read-only tools for listing pull requests and retrieving build status.
Offer an optional Streamable HTTP transport while keeping stdio as the default.
Publish versioned releases with simpler installation and upgrade paths.
Write operations will remain disabled by default. Approving, merging, and other high-impact Bitbucket operations are not planned. Ideas and implementation proposals are welcome through GitHub issues.
Development
npm run dev # Run directly from TypeScript
npm run build # Compile to dist/
npm test # Run the test suite once
npm run test:watch # Run tests in watch mode
npm run check # Build and test, matching CIThe command registry keeps each MCP tool isolated under src/tools. See CONTRIBUTING.md before opening a pull request.
Security
This server handles credentials in memory and sends them only to the configured BITBUCKET_URL. Review that URL carefully before starting the server. Enabling write tools allows connected MCP clients to create pull requests and publish PR comments as the authenticated Bitbucket user. To report a vulnerability privately, follow SECURITY.md.
License
Released under the MIT License.
Available Tools
3 toolsadd_pull_request_commentA
Creates a general, file, or inline line comment on a Bitbucket pull request. This is a write operation and requires BITBUCKET_ENABLE_WRITE_TOOLS=true.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket Cloud workspace ID or Bitbucket Server/Data Center project key | |
| repository | Yes | Repository slug or repository name | |
| pull_request_id | Yes | Pull request ID | |
| comment | Yes | Comment text. Bitbucket Cloud renders supported Markdown. | |
| file_path | No | Optional destination-side repository path for a file or line comment. | |
| source_file_path | No | Optional previous path for a renamed or copied file. Used by Server/Data Center. | |
| line | No | Optional 1-based diff line number. Requires file_path and line_type. | |
| line_type | No | Kind of diff line. Requires file_path and line. | |
| line_side | No | Diff side. Defaults to old for removed lines and new otherwise. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description declares write operation and environment variable requirement, but omits details on side effects, permissions, rate limits, or comment management (editing/deletion).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a note on prerequisites. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing explanation of return values (no output schema), no guidance on combining file_path, line, line_type, line_side for inline comments. Given 9 parameters and write nature, more context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter is documented in the schema. The description adds no extra semantic value beyond summarizing the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a comment on a Bitbucket pull request, specifying three types: general, file, or inline line comment. Different from sibling read-only tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly identifies it as a write operation requiring BITBUCKET_ENABLE_WRITE_TOOLS=true. Does not explicitly state when to use versus siblings, but the read-only nature of siblings implies the writing use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pull_requestA
Retrieves metadata, description, state/status, author, reviewers, source branch, destination branch, timestamps, and links for a specific Bitbucket pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket Cloud workspace ID or Bitbucket Server/Data Center project key | |
| repository | Yes | Repository slug or repository name | |
| pull_request_id | Yes | Pull request ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what data is retrieved but does not mention any behavioral traits such as authentication requirements, rate limits, or potential performance implications. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the retrieved data without any fluff. Every phrase adds value, and the structure is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does a good job of listing the expected return fields (metadata, description, state, author, reviewers, branches, timestamps, links). It is fairly comprehensive, though it could be improved by noting if any fields are nested or if there are pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters are described in the schema. The description adds no extra meaning beyond the schema; it simply restates that the tool retrieves for a specific pull request. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieves' and clearly lists the resource ('metadata, description, state/status, author, reviewers, source branch, destination branch, timestamps, and links for a specific Bitbucket pull request'). It distinguishes from sibling tools (add_pull_request_comment and get_pull_request_diff) by focusing on retrieval of metadata, not adding comments or getting diffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. While the purpose is clear, there is no guidance on when not to use it or which sibling tool to choose for other tasks. The agent must rely on tool names and context, which is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pull_request_diffA
Retrieves the raw diff and, when available, a structured list of changed files for a specific Bitbucket pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket Cloud workspace ID or Bitbucket Server/Data Center project key | |
| repository | Yes | Repository slug or repository name | |
| pull_request_id | Yes | Pull request ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions return content (raw diff and structured files) but does not discuss side effects, authentication needs, or limitations such as file size constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is direct and waste-free, conveying the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with three fully described parameters and no output schema, the description adequately states what is returned. Slightly incomplete in not mentioning that diff may be large or truncated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions (100% coverage). The tool description adds no extra meaning beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'retrieves' and resources 'raw diff' and 'structured list of changed files' for a specific Bitbucket pull request, distinguishing it from sibling tools like add_pull_request_comment and get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings; usage is implied by the name and description but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v1.0.0- First observed
add_pull_request_comment - First observed
get_pull_request - First observed
get_pull_request_diff
TDQS
Each tool targets a distinct aspect of pull requests: commenting, metadata retrieval, and diff retrieval. No functional overlap, making selection clear.
All tool names follow a consistent verb_noun snake_case pattern (add_*, get_*, get_*), which is predictable and easy to follow.
Three tools is minimal for a Bitbucket server; it covers only basic pull request read operations and commenting, missing core CRUD operations, but it is not extreme.
The toolset lacks essential operations like listing, creating, updating, or merging pull requests. Agents cannot perform a full workflow, leaving significant gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Human-authenticated setup for routing GitHub pull requests into the right Slack channel.
Human-authenticated setup for routing GitHub pull requests into the right Slack channel.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables management of Bitbucket Cloud pull requests through natural language, including creating, reviewing, approving, and commenting on PRs with automatic default reviewer support.791MIT
- AlicenseBqualityBmaintenanceEnables AI assistants to interact with Bitbucket Cloud and self-hosted instances for pull request reviews, code search, repository operations, and managing PR comments and approvals.19GPL 3.0
- AlicenseAqualityDmaintenanceEnables LLMs to review Bitbucket pull requests with custom checklists and API token authentication.51MIT
- AlicenseBqualityDmaintenanceEnables AI assistants to read Bitbucket Cloud pull requests and diffs through natural conversation.210MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/inceon/bitbucket-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server