Provides tools for reviewing Bitbucket Cloud pull requests, including listing and fetching PR details, viewing diffs and file contents, reading existing comments, and posting review comments.
Provides a tool to fetch a Jira issue with its linked issues and comments, giving context behind a pull request.
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 Review PR #123"
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.
An MCP server for reviewing Bitbucket Cloud pull requests. Claude Code, Cursor, or any other MCP client can read a pull request, the ticket behind it, and the comments already on it, then leave review comments, without you leaving the editor.
It is deliberately small, and it cannot change your repository. There is no tool to merge, approve, decline, push, delete a branch, or run a pipeline, so the token it asks for is two read scopes. An agent using it can read code and write comments. That is all it can do.
Authentication uses Atlassian API tokens, which replaced app passwords on 28 July 2026.
Needs Node 20 or newer.
git clone https://github.com/EnesPolovina/bitbucket-mcp
cd bitbucket-mcp
npm install
npm run build
cp .env.example .env # then fill it in, see Credentials below.env is gitignored, so it does not travel with the clone. It is the one thing
you set up per machine. The tokens themselves belong to your Atlassian account,
not to a machine, so the same ones work everywhere.
Check it before wiring it into a client:
./smoke.sh # lists open pull requests
./smoke.sh 42 # and fetches the diff for oneThe server reads .env only through smoke.sh. When a client launches it, the
values come from that client's config instead, so put them in both places.
Related MCP server: Bitbucket MCP
Go to https://id.atlassian.com/manage-profile/security/api-tokens and use Create API token with scopes, then pick Bitbucket. The plain Create API token button produces a token with no scopes, and the Bitbucket REST API answers those with a 401 and an empty body.
Two scopes, both read-only:
Scope | Covers |
| Reading the repository and its diffs |
| Listing pull requests, and commenting on them |
Commenting sits under the read scope, so the server never needs write access.
It cannot push, merge, approve, or delete anything. Add
read:pipeline:bitbucket if you want to be ready for pipeline support later.
Then set:
export ATLASSIAN_EMAIL="you@company.com" # your Atlassian account email
export BITBUCKET_API_TOKEN="..."The email is the one listed under Email aliases in Bitbucket personal settings, not your Bitbucket username.
Claude Code:
claude mcp add bitbucket -- node /absolute/path/to/bitbucket-mcp/dist/index.jsOr add it to your client's config file directly:
{
"mcpServers": {
"bitbucket": {
"command": "node",
"args": ["/absolute/path/to/bitbucket-mcp/dist/index.js"],
"env": {
"ATLASSIAN_EMAIL": "you@company.com",
"BITBUCKET_API_TOKEN": "..."
}
}
}
}Tool | What it does |
| Lists PRs, filtered by state, author, and branch |
| Title, description, author, state, branches |
| Which files changed and by how much, without the diff |
| The unified diff, truncated past |
| A whole file at the PR's commit, for the context a diff omits |
| Existing comments, with the file and line for inline ones |
| Posts a comment, optionally pinned to a file and line |
| The ticket, its links and its comments. Only if Jira is configured |
They take workspace and repo_slug. If you work in one repository, set
BITBUCKET_WORKSPACE and BITBUCKET_REPO_SLUG alongside the credentials and
drop them from the calls.
get_comments is what keeps a review from restating what a colleague already
wrote three days ago, which is the fastest way to make an automated reviewer
annoying.
Filtering matters more than it sounds. A page from Bitbucket holds 50 pull
requests, and a long-lived repository has thousands, so an unfiltered list is
mostly noise from other teams. list_pull_requests filters server-side and
follows pages until it has limit results:
Argument | Match | Example |
| exact, defaults to |
|
| exact account nickname |
|
| exact |
|
| substring |
|
| up to 200, defaults to 50 |
|
A diff tells you what changed. It cannot tell you whether that was what somebody
asked for. Set these two and get_jira_issue appears, carrying the ticket, its
linked issues and its comments:
export JIRA_BASE_URL="https://yourcompany.atlassian.net"
export JIRA_API_TOKEN="..."It needs its own token. A Bitbucket-scoped token cannot read Jira; it answers
401. ATLASSIAN_EMAIL is shared between the two.
Scopes: read:jira-work and read:jira-user, or their granular equivalents
read:issue:jira, read:comment:jira, read:user:jira. The user scope is what
puts a name on each comment.
Give it your ordinary site URL. Atlassian's two kinds of token want different hosts — a classic token authenticates against the site, a scoped one answers 401 there and has to go through a gateway addressed by cloud id. The server tries the site, and on a 401 looks the cloud id up and retries, so either kind of token works without you finding that id.
Leave them unset and the tool is never registered. A tool that is present but cannot authenticate is worse than an absent one, because the model finds it, calls it, and fails halfway through a task.
The comments matter as much as the description. A ticket that was reopened, or that carries a "this broke again in production" thread, means something different from its original text.
review_pull_request reads the ticket and the existing comments, pulls the diff,
and works through a checklist: correctness, edge cases, error handling, security,
test coverage, and scope creep. Findings come back worst first, each with a file,
a line, and the smallest fix.
The checklist that ships here is a starting point. The one worth having is specific to your codebase, and those specifics are usually the part you cannot publish. Keep it in a file outside this repository:
export REVIEW_CHECKLIST_PATH="$HOME/.config/review-checklist.md"Its contents replace the default. If the file is missing or empty the server logs that to stderr and falls back, so a bad path degrades the review instead of breaking it.
Write down failure modes, not incidents. "Anything writing to an audit trail has to be idempotent" is a lesson you can share. The outage that taught it to you usually is not.
npm testNo framework and no network. They cover the parts that can break quietly: a quote inside a filter cannot escape the query it is built into, the Jira tool is absent unless Jira is configured, the checklist falls back when its file is missing, and no registered tool can write to a repository.
MCP exposes capabilities that an agent may choose to call. It cannot gate a commit or force anyone through the checklist. If you want review standards enforced rather than offered, that belongs in a git hook or in CI, with this server alongside it.
get_pipeline_status, and reading a pull request's approval state.
MIT
Read existing comments on a pull request, so a review does not repeat points someone already raised. Inline comments carry the file and line they sit on.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum comments to return | |
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the useful detail that inline comments carry file and line, but does not discuss rate limits, pagination, or default behavior. This is adequate but not rich beyond the annotation.
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 two sentences long, front-loaded with the primary purpose, and contains no redundant information. Every sentence earns its place.
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 read-only tool with a fully documented schema and readOnlyHint annotation, the description adequately conveys purpose and a key data detail (inline comments have file/line). It doesn't enumerate all return fields, but no output schema exists; this is a minor gap.
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%, with each parameter clearly documented including defaults and examples. The description adds no parameter-specific meaning beyond what the schema already provides, 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 uses a specific verb and resource: 'Read existing comments on a pull request.' It clearly distinguishes itself from sibling tools like post_comment (write) and get_pull_request (PR metadata), and adds the purpose of avoiding duplicate review points.
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 phrase 'so a review does not repeat points someone already raised' provides a clear use case: check existing comments before posting a review. It doesn't explicitly name alternative tools or exclusions, but the context is clear among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the unified diff for a pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | Truncate the diff past this many characters | |
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already indicates this is a safe read operation, so the description does not need to repeat that. The description adds no extra behavioral details (e.g., truncation via max_chars), but it does not contradict the annotation. This is acceptable given the annotation coverage.
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 front-loads the core purpose. Every word earns its place, with no filler or redundancy. This is an example of ideal 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?
Given the simple nature of the tool, the annotations cover safety, and the schema fully documents parameters, the description is sufficient. The return format is implied (the diff), and no output schema exists, so a more detailed description could help but is not critical for this straightforward operation.
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?
Input schema description coverage is 100%, so all parameters (pull_request_id, max_chars, repo_slug, workspace) are already well-documented. The description adds no additional parameter meaning beyond what the schema provides, which meets the baseline for full schema coverage.
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 function with a specific verb ('Fetch') and resource ('the unified diff for a pull request'). This distinguishes it from sibling tools like get_diffstat (statistics) and get_pull_request (metadata), making the purpose immediately clear.
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 clear context for when to use the tool: to fetch the unified diff of a pull request. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous. A 4 is appropriate because it lacks explicit when-not-to-use guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which files a pull request touches and how many lines each gained or lost, without the diff itself. Use this first on a large pull request to decide what is worth reading.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation safe. The description adds valuable context about output scope (file-level line counts, not the diff content), clarifying behavior beyond the annotation. It does not address pagination or errors, but the safety profile is covered.
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?
Two sentences: the first states purpose, the second gives a pragmatic usage tip. Front-loaded, no redundant words, and every sentence earns its place.
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-only list tool with annotations and a clear schema, the description covers core behavior and usage context. The absence of an output schema is mitigated by describing what is returned (files with line counts), making the tool's invocation and expected result reasonably clear.
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 67%, covering repo_slug and workspace. The required pull_request_id lacks a description, but its meaning is obvious from the name and context. The description adds no parameter-level detail, relying on the schema, which is adequate.
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 specifies the tool's function: listing files changed in a pull request with per-file line gains/losses, explicitly excluding the full diff. This distinguishes it from the sibling tool get_diff by saying 'without the diff itself.'
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 explicit usage guidance: 'Use this first on a large pull request to decide what is worth reading.' It gives a clear scenario but does not explicitly name alternatives or exclusions, though the contrast with get_diff is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a whole file at the pull request's source commit. A diff shows changed lines but not the code around them, so use this when a hunk cannot be judged on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path within the repository, as it appears in the diff | |
| max_chars | No | Truncate past this many characters | |
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes | Pull request number, used to resolve the commit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, so the safety profile is covered. The description adds that it reads at the source commit, but it does not disclose truncation behavior via max_chars, error conditions, or return format. Minimal additional behavioral context beyond the annotation.
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 two sentences, front-loaded with the primary action and immediately followed by a practical use case. Every word earns its place with no redundancy or filler.
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 schema covers parameters and the annotation covers safety, the description provides sufficient context for selection. However, the claim of reading a 'whole file' is slightly misleading because max_chars defaults to 50000 and can truncate; the description does not mention this or the return behavior, and there is 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 coverage is 100%, so all five parameters have descriptions. The tool description does not add extra parameter meaning beyond the schema, so the 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 reads a whole file at the pull request's source commit, distinguishing it from diff tools that show changed lines only. The verb 'Read' and resource 'whole file at the pull request's source commit' are 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?
The description explicitly contrasts this tool with diff output and gives a concrete condition: 'when a hunk cannot be judged on its own.' This directly tells the agent when to use get_file versus get_diff, which is a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Title, description, author, state, and branches for one pull request. The description is what the change claims to do, which is what a review measures it against.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the read-only nature, and the description adds a valuable behavioral nuance: the 'description' field is the change's claim, which is what reviews measure against. It also lists expected return fields, helping the agent understand what data will come back.
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 two concise sentences: the first states the tool's purpose and scope, the second adds meaningful semantic context about the 'description' field. No wasted words or redundant 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?
With no output schema, the description compensates by listing the key returned fields and clarifying the meaning of 'description.' It is sufficiently complete for a simple read-only tool, though it could more explicitly frame this as a return value list.
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 descriptions cover repo_slug and workspace, but pull_request_id has no description beyond its name. The description's 'one pull request' implies selection by ID but does not explicitly explain the parameter. Added value over the schema is minimal.
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 states a specific verb and resource: 'Title, description, author, state, and branches for one pull request.' The explicit singular scope 'for one pull request' clearly distinguishes it from sibling tools like list_pull_requests and get_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?
The description implies usage when a single pull request's details are needed and mentions 'one pull request,' but it does not explicitly contrast with alternatives or state when not to use this tool. It provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pull requests in a Bitbucket Cloud repository.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum PRs to return. Pages are followed until this many are collected. | |
| state | No | Filter by PR state | OPEN |
| author | No | Filter by author account nickname, exact match, e.g. "Enes Polovina". Bitbucket can only filter on the nickname, which is usually the display name but is absent on many bot and service accounts. Use author_account_id for those. | |
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| source_branch | No | Filter by source branch, substring match, e.g. "PROJ" matches "fix/PROJ-142" | |
| author_account_id | No | Filter by author account_id. Exact, and works for accounts with no nickname. | |
| destination_branch | No | Filter by target branch, exact match, e.g. "main" or "release/2.4" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description itself adds no additional behavioral context, such as default filtering (state defaults to OPEN) or pagination behavior, which are captured in the schema. No contradiction exists.
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 concise sentence that directly states the tool's purpose with zero redundant words. It is front-loaded and easy to parse.
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 straightforward list operation with a rich schema (including defaults and filters) and a readOnlyHint annotation, the description provides enough context. It does not mention return values, but the name and tool nature imply a list of pull requests, and the schema covers behavior. Slight gap in not stating default state filtering, but acceptable.
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?
Input schema covers 100% of the 8 parameters with detailed descriptions, so the tool description does not need to explain parameters. It adds no parameter-level meaning beyond the schema, which aligns with the baseline 3 for high schema coverage.
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) and resource (pull requests) within a Bitbucket Cloud repository. It is specific but does not explicitly distinguish from the sibling tool get_pull_request, which presumably retrieves a single 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?
Usage is implied: use this tool to list multiple pull requests, as opposed to getting a single pull request. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a comment on a pull request. Provide path and line to attach it to a specific line of the diff.
| Name | Required | Description | Default |
|---|---|---|---|
| line | No | Line number in the new version of the file, requires path | |
| path | No | File path for an inline comment | |
| content | Yes | Comment body, Markdown | |
| repo_slug | No | Repository slug, e.g. "billing-api". Defaults to BITBUCKET_REPO_SLUG. | |
| workspace | No | Bitbucket workspace ID, e.g. "acme". Defaults to BITBUCKET_WORKSPACE. | |
| pull_request_id | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds context beyond annotations by explaining the line/diff attachment behavior, which is a meaningful behavioral detail. No contradictory or surprising traits are disclosed.
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 two sentences, front-loaded with the main action and a concise usage hint. Every word earns its place, with no redundancy.
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 write operation with full schema coverage and no output schema, the description covers the key usage (including inline comments). It does not describe the response format, but this is inferable and not a major gap given the tool's simplicity.
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 schema has 100% description coverage, so a baseline of 3 applies. The description adds value by clarifying the relationship between path and line for attaching comments to a specific line, which the schema only hints at via 'requires path'.
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 a specific verb+resource ('Post a comment on a pull request') and clearly distinguishes itself from the sibling get_* tools, which are all read-oriented. It also adds the specific capability of attaching to a line of 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?
The description implies the tool is for posting comments, and adds a hint about using path and line for inline comments. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of pull request review: file content, comments, diff, diffstat, PR metadata, and posting comments. There is no overlap between reading and writing operations.
All tools follow a consistent verb_noun pattern (get_*, list_*, post_*). The naming is predictable and clearly indicates the action and resource.
Seven tools is a well-scoped set for a pull request review workflow. Each tool serves a distinct purpose without redundancy or bloat.
The set covers the core review workflow: list PRs, view details, inspect diffs and files, read comments, and post feedback. It lacks actions like approving or merging, but those fall outside the stated review-focused purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP Server for JFrog, providing tools for development and artifact management.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
An MCP server that automatically collects feedback on your MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EnesPolovina/bitbucket-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
