Bitbucket Cloud MCP Server
Provides tools for retrieving pull request details and diffs from Bitbucket Cloud.
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 Cloud MCP ServerSummarize pull request #42 in the my-app repo"
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 Cloud MCP Server
An MCP (Model Context Protocol) server that lets AI assistants read Bitbucket Cloud pull requests. Connect Claude, Copilot, or any MCP-compatible client to your Bitbucket Cloud workspace and review PRs through natural conversation.
What Can It Do?
Tool | Description |
| Retrieve pull request details (title, author, status, branches, etc.) |
| Get the full diff of a pull request |
Example prompts you can use with your AI assistant:
"Summarize pull request #42 in the my-app repo"
"Review the diff for PR #15 and suggest improvements"
"What's the status of open PRs in our project?"
Related MCP server: Bitbucket MCP Server
Quick Start
1. Install
git clone https://github.com/ttekun/bitbucket-cloud-mcp-server.git
cd bitbucket-cloud-mcp-server
npm install
npm run build2. Get a Bitbucket App Password
Go to Bitbucket Cloud → Personal Settings → App passwords
Create a new app password with Repository: Read and Pull request: Read permissions
3. Configure Your MCP Client
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"bitbucket-cloud": {
"command": "node",
"args": ["/absolute/path/to/bitbucket-cloud-mcp-server/build/index.js"],
"env": {
"BITBUCKET_TOKEN": "your-app-password",
"BITBUCKET_WORKSPACE": "your-workspace"
}
}
}
}Add to your VS Code settings or .vscode/mcp.json:
{
"mcpServers": {
"bitbucket-cloud": {
"command": "node",
"args": ["/absolute/path/to/bitbucket-cloud-mcp-server/build/index.js"],
"env": {
"BITBUCKET_TOKEN": "your-app-password",
"BITBUCKET_WORKSPACE": "your-workspace"
}
}
}
}Environment Variables
Variable | Required | Description |
| Yes | Bitbucket Cloud app password |
| No | Default workspace (can be overridden per request) |
Tool Parameters
Both tools accept the same parameters:
Parameter | Type | Required | Description |
| string | Yes* | Bitbucket workspace (*falls back to |
| string | Yes | Repository slug |
| number | Yes | Pull request ID |
Development
npm run dev # Watch mode
npm test # Run tests
npm run lint # Lint
npm run inspector # MCP Inspector (debug tool)License
Available Tools
2 toolsget_bb_diffB
Get pull request diff from Bitbucket Cloud
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace | |
| repo_slug | Yes | Repository slug | |
| 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 must fully disclose behavior. It only says 'get', implying a read operation, but reveals no additional traits such as idempotency, size limits, or authentication needs.
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, front-loaded with the core action. No extraneous words. Perfectly concise.
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?
The tool has three required parameters and no output schema. The description is adequate but minimal; it does not explain the format of the diff or any pagination/limitations. Meets minimum viability.
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?
All three parameters are described in the input schema (100% coverage). The description adds no extra meaning beyond the schema, so baseline 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 clearly states the verb 'get' and resource 'pull request diff from Bitbucket Cloud'. It distinguishes from the sibling 'get_bb_pull_request', which likely retrieves PR details rather than the diff.
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 guidance on when to use this tool versus the sibling 'get_bb_pull_request'. The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bb_pull_requestA
Get pull request details from Bitbucket Cloud
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace | |
| repo_slug | Yes | Repository slug | |
| pull_request_id | Yes | Pull request ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get pull request details' correctly implies a read-only operation, but no additional behaviors (e.g., authentication requirements, rate limits, or error handling) are disclosed. It is adequate but minimal.
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 clear sentence that efficiently conveys the tool's purpose without any unnecessary words.
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 simple read tool with three well-described parameters, the description is minimally sufficient. However, lacking an output schema, it does not specify what fields or structure the response contains, which could reduce completeness.
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?
All three parameters are documented in the input schema with descriptions. The tool description does not add extra meaning beyond the schema, so 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 clearly states the verb 'Get' and resource 'pull request details', specifying the platform 'Bitbucket Cloud'. It distinguishes itself from the sibling tool 'get_bb_diff', which retrieves diffs, making the tool's purpose unambiguous.
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 provides no guidance on when to use this tool versus alternatives, such as when to call get_bb_diff instead. No when-not-to-use or prerequisite information is included.
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.
2 tool updates
v1.0.0- First observed
get_bb_diff - First observed
get_bb_pull_request
TDQS
The two tools, 'get_bb_diff' and 'get_bb_pull_request', have distinct purposes: one retrieves a pull request diff, the other retrieves pull request details. There is no overlap or ambiguity between them.
Both tools follow a consistent 'get_bb_{resource}' pattern, using snake_case and a clear prefix 'get_bb'. The naming is predictable and uniform.
With only 2 tools, the server feels thin for a Bitbucket Cloud integration. While not extremely mismatched, it is below the typical 3-15 range and borders on insufficient.
The tool surface is severely incomplete for a Bitbucket Cloud server. It only provides read operations for pull requests, lacking CRUD operations for repos, branches, commits, and other essential resources.
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
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to interact with Bitbucket Cloud repositories, allowing users to manage pull requests, comments, tasks, and branches through natural language commands.5,0331MIT
- AlicenseAqualityDmaintenanceEnables management of Bitbucket Cloud pull requests through natural language, including creating, reviewing, approving, and commenting on PRs with automatic default reviewer support.791MIT
- AlicenseBqualityDmaintenanceEnables 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
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to programmatically manage Bitbucket Cloud resources, including pull requests, repositories, and branches, automating code review workflows.33MIT
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/ttekun/bitbucket-cloud-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server