Provides tools for managing Bitbucket Server repositories and pull requests, including creating, updating, merging, declining, and deleting pull requests, adding comments and inline code suggestions, retrieving diffs and review status, and listing repositories, branches, and pull requests.
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 Server MCP list open pull requests in project PROJ"
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.
A professional Model Context Protocol (MCP) server for Bitbucket Server, enabling seamless automation and integration for pull request management, code review, and repository operations.
Related MCP server: Bitbucket MCP Server
Bitbucket Server MCP provides a robust interface for automating and managing Bitbucket Server repositories and pull requests via the Model Context Protocol. Designed for enterprise environments, it supports advanced workflows, large diffs, and seamless integration with MCP clients.
List repositories, branches, and pull requests
Create, update, and merge pull requests (merge-commit, squash, fast-forward)
Decline and delete pull requests
Add comments and inline code suggestions
Retrieve pull request diffs and review status
Efficient handling of large pull request diffs
Extensible tool handler wiring for MCP protocol
Cross-platform support (Windows, Mac, Linux)
Run directly without cloning:
npx -y bitbucket-server-mcpClone and build the project:
git clone https://github.com/your-org/bitbucket-server-mcp.git
cd bitbucket-server-mcp
npm install
npm run buildCopy .env.example to .env and configure your Bitbucket Server credentials.
Start the MCP server:
npm start
# or
node build/index.jsAdd the following to your MCP configuration (e.g., cline_mcp_settings.json):
{
"servers": [
{
"name": "bitbucket-server-mcp",
"command": "npx",
"args": ["-y", "bitbucket-server-mcp"],
"env": {
"BITBUCKET_URL": "https://your-bitbucket-server",
"BITBUCKET_TOKEN": "your-access-token",
"BITBUCKET_DEFAULT_PROJECT": "your-default-project",
"BITBUCKET_DEFAULT_REVIEWERS": "user1,user2"
}
}
]
}If npx is unavailable, configure as follows:
Windows:
"command": "node",
"args": ["C:\\path\\to\\bitbucket-server-mcp\\build\\index.js"],Mac/Linux:
"command": "node",
"args": ["/path/to/bitbucket-server-mcp/build/index.js"],Variable | Description | Required | Example |
| Bitbucket Server base URL | Yes |
|
| Personal access token | Yes |
|
| Default project key | No |
|
| Comma-separated reviewer usernames | No |
|
| Username (if not using token) | No |
|
| Password (if not using token) | No |
|
See .env.example for details.
Lint code:
npm run lintRun in watch mode:
npm run devRun the test suite:
npm testContributions are welcome! Please open issues or submit pull requests for new features, bug fixes, or improvements.
This project is licensed under the MIT License.
Add a comment to a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| text | Yes | Comment text | |
| parentId | No | Parent comment ID for replies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and only a six-word description, behavioral traits such as whether the comment is appended, limits, or error handling are completely absent. The description adds no value beyond the tool's name.
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?
At 6 words, the description is extremely concise but lacks structure; it could include more information without sacrificing brevity.
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 5 parameters (3 required) and no output schema. The description fails to explain return values, error conditions, or how to use the parentId parameter. It is insufficient for complete understanding.
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?
The parameter schema already has 100% coverage with descriptions for all parameters. The description does not add any further meaning or context about how parameters interact, so baseline 3 applies.
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 'Add a comment to a pull request' clearly states the verb 'Add' and the resource 'comment to a pull request', which is specific and distinct from sibling tools like add_inline_comment or approve_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?
The description provides no guidance on when to use this tool versus alternatives like add_inline_comment or other PR actions. No prerequisites or context for effective use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an inline comment to a file in a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| text | Yes | Comment text | |
| filePath | Yes | Path to the file in the repository | |
| line | Yes | Line number to comment on | |
| lineType | No | Type of line (default is CONTEXT) | |
| startColumn | No | Starting column for code highlight (optional) | |
| endColumn | No | Ending column for code highlight (optional) | |
| parentId | No | Parent comment ID for replies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. However, it gives no behavioral details such as authentication requirements, rate limits, side effects (e.g., triggers notifications), or whether the comment is immediately visible. The agent has no information beyond the basic action.
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 of 10 words, very concise. However, given the tool has 10 parameters and no annotations, it is underspecified. The brevity sacrifices completeness, earning a middle score.
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?
With 10 parameters, no output schema, and no annotations, the description is insufficient. It does not explain how optional parameters like 'startColumn'/'endColumn' or 'parentId' work, nor the semantics of 'lineType' enum. An agent would lack critical context to use the tool correctly.
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%, so each parameter already has a description. The tool description adds no extra meaning beyond what is in the schema, so baseline 3 is appropriate. It does hint at the purpose of 'filePath' and 'line' but not beyond rubric.
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 action: 'Add an inline comment to a file in a pull request.' This specifies the verb (add), resource (inline comment), and context (file in a pull request). It distinguishes from sibling tool 'add_comment' which likely adds general comments.
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 is provided on when to use this tool versus alternatives like 'add_comment' or 'suggest_code_change.' The description lacks any when-to-use or when-not-to-use information, leaving the agent to infer from the name only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without explaining behavioral traits such as required permissions, reversibility, or effects (e.g., triggering CI). No annotations are provided to compensate.
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 extremely concise and front-loaded, with a single sentence that directly states the purpose.
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 action like approving a PR, the description is minimally adequate. However, it omits context such as side effects, relationship to sibling tools, and any necessary preconditions.
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?
The input schema already provides descriptions for all three parameters, and the tool description adds no additional meaning beyond what is in the schema.
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 action and resource: 'Approve a pull request'. It effectively distinguishes from sibling tools like decline_pull_request and unapprove_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 guidance is given on when to use this tool versus alternatives (e.g., unapprove_pull_request). There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| title | Yes | PR title | |
| description | No | PR description | |
| sourceBranch | Yes | Source branch name | |
| targetBranch | Yes | Target branch name | |
| reviewers | No | List of reviewer usernames |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral disclosure such as success/error cases, permissions, or side effects. For a mutation tool, this is a significant gap.
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 very concise (one sentence), but it adds little value beyond the tool name. It could be slightly expanded to provide context without being verbose.
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?
With 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, prerequisites, or behavioral details, leaving significant gaps for an agent.
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% with descriptions for each parameter. The tool description adds no additional parameter 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?
Description clearly states the verb and resource: 'Create a new pull request'. However, it does not differentiate from sibling tools like 'merge_pull_request' or 'approve_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 guidance on when to use this tool vs alternatives. Sibling tools include many PR actions, but no usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decline a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| message | No | Reason for declining |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only states the action without any details on side effects, permissions required, or consequences (e.g., notifications, reversibility). This leaves the agent with minimal insight.
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, front-loaded sentence that efficiently conveys the core purpose. However, it is too concise and could benefit from additional structured details without being verbose.
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 is a mutation with four parameters and no output schema, yet the description provides no information about return values, side effects, or preconditions. It is insufficient for an agent to fully understand the tool's impact.
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?
The input schema already provides descriptions for all four parameters (100% coverage). The description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance understanding.
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 'Decline a pull request' clearly states the action and resource, using a specific verb. It effectively distinguishes this tool from sibling tools like 'approve_pull_request' or 'merge_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 guidance is provided on when to use this tool versus alternatives such as 'delete_pull_request' or 'merge_pull_request'. The description lacks context about appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a pull request by declining it
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| message | No | Reason for deleting/declining |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It conflates 'delete' and 'decline' without explaining the actual outcome (e.g., soft delete vs hard delete, reversibility, or permissions needed).
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 extremely concise (one phrase), which is efficient but at the expense of necessary detail. It lacks structure and does not provide a complete sentence.
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 the lack of output schema and the tool's mutation nature, the description is too brief. It fails to explain return values, side effects, required permissions, or what happens after deletion. The agent lacks sufficient context to use the tool confidently.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond what the parameter descriptions provide; it renames the action but does not clarify parameter usage.
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 tool deletes a pull request by declining it, providing a specific verb and resource. However, it does not distinguish from the sibling tool 'decline_pull_request', which may imply the same action, creating ambiguity.
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 alternatives, especially the closely related 'decline_pull_request'. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pull request diff
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| contextLines | No | Number of context lines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action without revealing traits like idempotency, read-only nature, or output format. The agent lacks insight into side effects or 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?
The description is very concise (one sentence), which is good, but it is too brief for a tool with four parameters. It sacrifices helpfulness for brevity, resulting in minimal adequacy.
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 the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It fails to explain return values, parameter usage, or how the diff is structured, leaving significant gaps for agent understanding.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, meeting the baseline but providing no extra value.
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 tool's action ('get') and resource ('pull request diff'), distinguishing it from sibling tools like get_pull_request which retrieves metadata. The purpose is specific and 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?
No usage guidelines are provided. The description does not indicate when to use this tool vs alternatives such as get_pull_request or list_pull_requests, nor does it specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pull request details
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('Get'), so it is likely non-destructive. However, without annotations, the description does not explicitly state behavioral traits like idempotency, rate limits, or authentication requirements. It is minimally transparent.
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, concise sentence that is to the point. While it could include more detail, it is not overly verbose and is well-structured for quick comprehension.
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 the absence of an output schema, the description does not clarify what 'details' includes, which could lead to uncertainty. With sibling tools offering specific data, this description is somewhat incomplete.
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?
The input schema covers all three parameters with descriptions, achieving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
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 'Get pull request details' clearly indicates the action (get) and the resource (pull request details). However, it does not differentiate from sibling tools like get_diff or get_pull_request_comments, which also retrieve pull request information. The term 'details' is somewhat vague.
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 is provided on when to use this tool versus alternatives. For example, users are not told that get_pull_request_comments is better for comments or get_diff for diffs. This lack of usage context reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all comments on a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states 'get all comments', implying a read-only operation, but does not clarify whether inline comments are included, or whether there are pagination limits. This is adequate for a simple read tool but lacks depth.
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 of 5 words, conveying essential information with zero waste. It is appropriately front-loaded and 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?
Given the tool's simplicity (3 required parameters, no output schema), the description is almost complete. It might benefit from noting whether comments include metadata or are sorted, but for a basic getter, it is sufficient.
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%, so the input schema already documents all parameters thoroughly. The description adds no extra meaning beyond the parameter names and their schema descriptions, meeting the baseline.
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 'Get all comments on a pull request' is a specific verb+resource, clearly differentiating from sibling tools like add_comment (write) and get_reviews (which returns approvals, not comments). It leaves no ambiguity about the tool's function.
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 vs. alternatives such as get_reviews or add_inline_comment. There is no mention of prerequisites (e.g., need pull request ID) beyond the required parameters, nor exclusions for when this might not be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the entire repository as a zip or tar archive
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key | |
| repository | Yes | Repository slug | |
| format | No | Archive format (zip or tar, default is zip) | |
| at | No | Branch or commit to download (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It fails to disclose potential issues like large download size, streaming behavior, default format, or effects of the 'at' parameter. Basic behavioral traits are missing.
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, no wasted words. Front-loaded with the verb and resource. Highly 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?
No output schema or annotations. Description omits critical context: handling of large repos, default format, streaming response, and behavior for missing 'at' parameter. Incomplete for a download tool.
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% with parameter descriptions. The description adds minimal value beyond schema (e.g., 'entire repository' reinforces scope). Baseline 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 action ('download'), the resource ('entire repository'), and the format ('zip or tar archive'). It uniquely identifies the tool among siblings focused on pull requests and comments.
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 alternatives. The context implies it's the only download archive tool, but no mention of prerequisites (e.g., access rights) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a repository
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key | |
| repository | Yes | Repository slug |
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 only says 'get details' without disclosing whether it is a read-only operation, required permissions, or potential side effects. A simple read hint or mention of safety would improve transparency.
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 at 5 words, no wasted words. However, the brevity sacrifices useful context; a slightly longer description could enhance clarity without losing conciseness.
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 lacks an output schema, and the description does not explain what 'details' are returned. Given the simplicity (2 required params), the agent needs to know return format or fields to expect, which is missing.
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% (project key and repository slug are documented). The description adds no extra meaning beyond what the schema already provides, so baseline 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 tool gets repository details, which distinguishes it from list_repositories (listing all) and get_pull_request (specific PR). However, it does not specify what 'details' entails, leaving some ambiguity.
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 alternatives (e.g., list_repositories for browsing, get_pull_request for a PR). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pull request reviews
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details (e.g., read-only nature, pagination, required permissions). The tool's behavior is entirely opaque beyond the basic action.
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, short sentence with no wasted words. However, it could be more informative without sacrificing brevity.
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 the lack of an output schema and the tool's purpose to retrieve reviews, the description should explain what is returned (e.g., list of reviewers, status) or any limitations. It does not, leaving the agent underinformed.
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 fully described in the input schema (100% coverage), so the description adds no extra meaning. Baseline score of 3 is appropriate since the schema already documents parameter semantics.
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 'Get pull request reviews' clearly identifies the action and resource, but it adds minimal differentiation from sibling tools like 'get_pull_request' or 'get_pull_request_comments'. It is adequate but not specific.
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 is provided on when to use this tool versus alternatives such as 'get_pull_request_comments' or 'approve_pull_request'. The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all branches in a repository
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key | |
| repository | Yes | Repository slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks behavioral details like pagination, access requirements, or output format.
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, no fluff. Could be expanded with useful context without losing conciseness.
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?
Minimal for a simple list tool. Lacks mention of sorting, filtering, or output details. No output schema.
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 both parameters with descriptions (100% coverage). Description adds no extra meaning.
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?
Clear verb+resource: 'List all branches in a repository.' Distinct from sibling tools like list_pull_requests.
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 or alternatives. No context for parameter values beyond schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pull requests for a repository in a Bitbucket project
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key | |
| repository | Yes | Repository slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Does not disclose behavior like pagination, ordering, state of returned PRs, or required permissions. Merely says 'list all' which is vague.
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?
One sentence, concise and to the point. However, lacks structure; could be more informative within the same length.
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 and sibling tools, description is incomplete. Does not mention what is returned (e.g., list of pull request objects) or any default behavior.
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 100% of parameters with descriptions, so baseline is 3. Description does not add additional meaning beyond what schema provides.
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 lists pull requests for a repository in a Bitbucket project. However, does not differentiate from siblings like 'get_pull_request' which retrieves a specific one, but the verb 'list' implies multiple.
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 alternatives. For example, does not mention filtering, sorting, or that it returns all PRs (possibly with pagination).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all repositories in a Bitbucket project
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Bitbucket project key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry behavioral context. It only states a read operation but lacks details on pagination, rate limits, permissions, or error behavior.
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?
A single, well-formed sentence that conveys the purpose without excess. It is appropriately front-loaded and efficient.
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 listing tool with no output schema, the description is adequate but could mention potential pagination or a hint about the output format to be fully complete.
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% (the sole parameter has a schema description). The tool description adds no extra meaning beyond what the schema already provides.
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 action (list), resource (repositories), and scope (all in a Bitbucket project). It naturally distinguishes from sibling tools like list_branches and list_pull_requests which target different entities.
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 versus alternatives. The description does not mention when not to use it or highlight other tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| message | No | Merge commit message | |
| strategy | No | Merge strategy to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must disclose behaviors. Only says 'merge a pull request'; fails to mention side effects like branch updates, CI triggers, or access requirements.
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 concise sentence with no unnecessary words. Every word contributes to purpose.
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?
Despite only 5 parameters and no output schema, the description is too bare. Lacks context on merge behavior, conflict handling, and required prior steps (e.g., approvals).
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 has 100% description coverage for all 5 parameters, so baseline is 3. Description adds no extra meaning beyond the schema, but no contradiction.
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 'merge' and resource 'pull request', making purpose obvious. It distinguishes from sibling tools like approve or decline, but does not explicitly differentiate.
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 alternatives, such as when to merge vs. decline or approve. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a code suggestion comment to a file in a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID | |
| filePath | Yes | Path to the file in the repository | |
| line | Yes | Line number to comment on | |
| lineType | No | Type of line (default is CONTEXT) | |
| message | No | Comment message explaining the suggestion (optional) | |
| suggestedCode | Yes | The suggested code | |
| parentId | No | Parent comment ID for replies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. Annotations are absent, so the description carries the full burden. It fails to mention permissions, side effects (e.g., thread creation), or response behavior.
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 concise sentence with no wasted words. It is front-loaded and efficiently communicates the core purpose.
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?
Despite having 9 parameters and no output schema, the description is minimal. It does not explain what the tool returns, prerequisites, or how the suggestion is presented, making it incomplete for the complexity of the tool.
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?
The input schema has 100% description coverage, meaning each parameter is already described. The tool description adds no additional meaning beyond the schema, so a 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 action (add) and the resource (code suggestion comment) within a specific context (file in a pull request). It is distinct from siblings like add_comment and add_inline_comment, though it does not explicitly differentiate them.
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 is provided on when to use this tool versus alternatives. Siblings like add_comment and add_inline_comment serve similar purposes, but the description offers no criteria for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unapprove (reject approval for) a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Bitbucket project key | |
| repository | Yes | Repository slug | |
| prId | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the destructive action (rejecting approval) but does not disclose consequences, such as whether the PR state changes, if it can be undone, or any side effects like notifications.
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 extremely concise, using a single sentence to convey the core action. It is front-loaded with the verb and resource, with no 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?
Given the tool's simplicity (3 simple parameters, no output schema), the description is minimally adequate but lacks behavioral context such as user requirements or side effects. It covers the action but not the full usage context.
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% with all three parameters described in the input schema. The description adds no extra meaning beyond the schema, meeting the baseline for parameter semantics.
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 tool's purpose: unapproving (rejecting approval for) a pull request. It uses a specific verb and resource, and directly contrasts with the sibling tool 'approve_pull_request', making its unique role obvious.
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 or any prerequisites (e.g., must have previously approved, required permissions). It only states the action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.3add_commentadd_inline_commentapprove_pull_requestcreate_pull_requestdecline_pull_requestdelete_pull_requestget_diffget_pull_requestget_pull_request_commentsget_repository_archiveget_repository_detailsget_reviewslist_brancheslist_pull_requestslist_repositoriesmerge_pull_requestsuggest_code_changeunapprove_pull_requestMost tools are distinct, but add_comment and add_inline_comment have overlap (inline is a subtype), and get_pull_request_comments vs get_reviews may confuse an agent. Overall, clear boundaries for most.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., list_repositories, get_pull_request. No mixing of styles or irregularities.
18 tools is well-scoped for a Bitbucket server MCP, covering repositories, branches, and pull requests with comments and reviews. Neither too few nor excessive.
Core PR lifecycle is covered (create, get, list, approve, merge, decline), but missing update_pull_request and branch management beyond listing (create, delete branch). Archive and details are present, but some operations are absent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for JFrog, providing tools for development and artifact management.
A MCP server built for developers enabling Git based project management with project and personal…
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ManiKsi/bitbucket-server-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server