Allows interaction with Bitbucket Cloud, providing tools for managing pull requests, repositories, branches, files, issues, and more, with support for the full Bitbucket Cloud REST API.
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., "@MCP Bitbucket List all open pull requests in the current repository."
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 Bitbucket Cloud ā pull request review, repository and source tools, and a searchable index of all 294 REST endpoints so the model can reach anything the typed tools do not wrap.
Derived from and substantially rewritten out of Kallows/mcp-bitbucket ā see Credits & Acknowledgments.
Complete API coverage. Two tools ā bb_list_endpoints and bb_request ā
reach every Bitbucket Cloud 2.0 endpoint, so a missing typed tool is never a
dead end. The endpoint index is generated from Atlassian's official OpenAPI
spec and cannot drift from the published docs.
Pull request review tools built for reviewing rather than for API completeness: per-file diffs, trimmed PR listings, inline comments, approvals.
Zero-config repo targeting. The workspace and repo slug are read from the git remote of the directory the client was launched in, so one registration serves every Bitbucket checkout.
Two auth modes. Scoped API tokens (preferred) or legacy app passwords.
Safe by default. Writes through the generic proxy are opt-in, repository deletion is not registered unless explicitly enabled, request logging is off, and every tool is annotated so your client can tell a read from a deletion.
Related MCP server: Bitbucket MCP Server
Requires Python 3.12+.
git clone https://github.com/mohitgoel188/mcp-bitbucket.git
cd mcp-bitbucket
# with uv (recommended)
uv sync
# or with pip
pip install -e .Register the server with your MCP client, pointing at the interpreter from the virtualenv you just created.
Do not launch this server with uv run --directory. That flag changes the
process working directory to this repo, which breaks
repository auto-detection ā every call would
resolve to mcp-bitbucket instead of the repo you are working in. Invoke the
interpreter directly, as shown below.
claude mcp add bitbucket \
--env BITBUCKET_TOKEN=your-api-token \
-- /absolute/path/to/mcp-bitbucket/.venv/bin/python -m mcp_bitbucket.server~/Library/Application Support/Claude/claude_desktop_config.json on macOS,
%APPDATA%\Claude\claude_desktop_config.json on Windows:
{
"mcpServers": {
"bitbucket": {
"command": "/absolute/path/to/mcp-bitbucket/.venv/bin/python",
"args": ["-m", "mcp_bitbucket.server"],
"env": {
"BITBUCKET_TOKEN": "your-api-token"
}
}
}
}On Windows the command is
C:\\path\\to\\mcp-bitbucket\\.venv\\Scripts\\python.exe ā note that JSON
requires each backslash to be doubled.
Copy .env.example as a starting point.
# Preferred: a scoped API token or repository access token. No username needed.
# A token wins when both modes are configured, because Atlassian is migrating
# Bitbucket Cloud off app passwords onto scoped tokens.
export BITBUCKET_TOKEN="your-api-token"
# Legacy: username + app password.
export BITBUCKET_USERNAME="your-username"
export BITBUCKET_APP_PASSWORD="your-app-password"The server refuses to start with neither, naming what to provide.
To create a token: Bitbucket ā Settings ā API tokens (or App passwords for
the legacy mode). Grant only the scopes you need ā repository and
pullrequest cover most usage; add :write variants for the write tools.
# Workspace. Optional inside a Bitbucket checkout (read from the git remote),
# required otherwise. There is no built-in default.
export BITBUCKET_WORKSPACE="your-workspace"
# Repo slug. Same rule ā auto-detected inside a checkout.
export BITBUCKET_REPO_SLUG="your-repo"
# Point auto-detection at a directory other than the process cwd.
export BITBUCKET_PROJECT_DIR="/path/to/some/checkout"# Allow non-GET requests through bb_request. Default "true" (reads only).
# Leave it on unless you want the model able to call any write endpoint.
export BITBUCKET_BB_REQUEST_READONLY="false"
# Register bb_delete_repository at all. Default "false".
export BITBUCKET_ALLOW_DESTRUCTIVE="true"The typed write tools (bb_write_file, bb_pr_comment, bb_pr_approve, ā¦) are
not affected by these switches ā they are always available. The switches
govern the generic proxy and repository deletion specifically.
# Log every request as a runnable curl command. Default "false".
# Read the Security section before enabling this.
export BITBUCKET_ENABLE_REQUEST_LOGGING="true"
# Where to write it. Default: ./bitbucket_requests.log, relative to the cwd.
export BITBUCKET_REQUEST_LOG_FILE="/tmp/bitbucket_requests.log"23 tools. Two cover the entire REST API; the rest are typed conveniences for the
highest-traffic operations. workspace and repo_slug are optional wherever
they appear ā see auto-detection.
Tool | What it does |
| Search all 294 endpoints for the right method, path and params. Every whitespace-separated term must match, so |
| Call any Bitbucket Cloud 2.0 endpoint. The escape hatch for merges, commit comparison, branches and tags, pipelines, code search, webhooks, permissions. |
The intended flow is discover, then call:
bb_list_endpoints(search="comment pull request", method="POST")
-> POST /repositories/{workspace}/{repo_slug}/pullrequests/{pull_request_id}/comments
bb_request(method="POST",
path="/repositories/myworkspace/myrepo/pullrequests/123/comments",
body={"content": {"raw": "Looks good"},
"inline": {"path": "src/example.py", "to": 42}})paginate=true follows Bitbucket's next links and merges every page's
values, capped by max_pages. raw=true returns the body verbatim, which is
what the diff, patch and pipeline-log endpoints need since they answer in
text/plain. The fields query param trims large responses and materially cuts
token cost.
Tool | What it does |
| List PRs by state, source/destination branch or author. The |
| PR details, optionally with comments, commits and diff. |
| Open a PR from a source branch. |
| Per-file added/removed counts without the diff bodies. |
| One file's diff out of the combined PR diff. |
| The PR diff split per file. |
| A file's full content at the PR's source commit. |
| Comments, flagging inline location, replies and resolved threads. |
| Comment on a PR. |
| Mark a comment thread resolved. |
| Approve, as the authenticated user. |
| Request changes, as the authenticated user. |
The last five are visible to your team and mostly irreversible. The server tells the model to confirm intent first, but that is guidance, not enforcement.
Tool | What it does |
| Search with Bitbucket's query syntax, e.g. |
| Create a repository. |
| Create a branch from a start point. |
| Read a file at a branch or commit. |
| Create or update a file, with a commit message. |
| Delete a file. |
| Create an issue with kind and priority. |
| Delete an issue. |
| Delete a repository. Not registered unless |
The server reads the workspace and repo slug from the git remote of its working
directory, so one user-level registration serves every Bitbucket checkout ā
repo_slug becomes optional and defaults to whichever repo the session was
opened in. Both SSH and HTTPS remote forms are recognised.
Precedence is explicit env ā detected ā unset:
Setting | Env override | Detected from | If neither |
Workspace |
|
| required per call |
Repo slug |
|
| required per call |
There is deliberately no fallback workspace. When nothing resolves, calls
fail with an explicit "pass workspace and repo_slug explicitly, or set
BITBUCKET_WORKSPACE" message rather than an opaque 404 ā or worse, a silent
request against somebody else's workspace.
bb_list_endpoints reads src/mcp_bitbucket/endpoints.json, generated from the
same OpenAPI spec that renders
the official REST docs.
Each entry carries the method, path, tag, summary, path/query parameters, whether
it accepts a body, and a deep link to its docs section.
Regenerate it when Atlassian ships API changes:
# Uses a cached copy of the spec if it is less than 24h old
uv run python scripts/generate_endpoints.py
# Bypass the cache entirely
uv run python scripts/generate_endpoints.py --force
# Revalidate against the server instead of trusting the TTL
uv run python scripts/generate_endpoints.py --max-age 0The spec is cached under .spec-cache/ with its ETag. A TTL gate keeps repeat
runs off the network; ETag revalidation is attempted too, but the dac-static
CDN drops its ETag on the gzip variant it serves (it sets
Vary: Accept-Encoding), so only the api.bitbucket.org/swagger.json mirror can
actually answer 304. The generator refuses to overwrite the index if the spec
yields zero operations, and skips the write entirely when nothing changed.
Worth understanding before you point this at a repository you care about.
The working directory decides the target. Auto-detection runs at import time
against the process cwd, which the client sets to your project. That is what
makes one registration work everywhere, but it also means the model can act on
whichever repo the session was opened in without naming it. Set
BITBUCKET_WORKSPACE / BITBUCKET_REPO_SLUG explicitly if you want a fixed
target.
bb_request reaches every endpoint. With BITBUCKET_BB_REQUEST_READONLY
at its default of true it refuses everything but GET. Turning it off grants
the model any write your credential can perform, including endpoints no typed
tool wraps.
Scope your credential. The server enforces nothing about permissions ā the token does. A read-scoped token is the strongest available guard rail.
Request logging writes bodies to disk. When
BITBUCKET_ENABLE_REQUEST_LOGGING is on, each request is appended as a runnable
curl command. Credentials are redacted ā the Authorization header and both
halves of basic auth ā but request bodies are written verbatim, which for
bb_write_file means file contents and for bb_pr_comment means comment text.
The file is relative to the cwd by default, so it lands inside your project and
grows unrotated. It is off by default for these reasons; review a log before
sharing it.
Tool annotations are hints. Every tool carries readOnlyHint /
destructiveHint so your client can prompt appropriately, and
bb_delete_repository is withheld from the schema entirely unless enabled.
These help a well-behaved client; they are not server-side enforcement.
To report a vulnerability, see SECURITY.md.
# Everything that runs offline (fully mocked, no credentials, no network)
python -m unittest tests.test_bb_api tests.test_auth_modes tests.test_stdio_handshake
# Lint and format
uv run ruff check .
uv run ruff format .tests/test_bb_integration.py is excluded above deliberately: it hits the
real Bitbucket API and creates and deletes real repositories. It skips
unless credentials and BITBUCKET_TEST_WORKSPACE are set. See
tests/README.md.
Pick the module under src/mcp_bitbucket/tools/ by API area, or add one and
register it in tools/__init__.py.
Inside register(server), add @server.tool(annotations=..., description=...)
on an async def bb_* with keyword-only params, each
Annotated[T, Field(description=...)]. The signature is the JSON Schema.
Default workspace / repo_slug to the config values.
Call through http_client.request() + api_url(), then require_ok().
Return trimmed, human-readable text ā every token lands in someone's context.
Descriptions are prompt engineering, not documentation: they are the only thing the model sees when choosing a tool.
src/mcp_bitbucket/
āāā server.py # MCPServer assembly + stdio entry point
āāā config.py # environment-derived settings, repo auto-detection
āāā http_client.py # auth, curl logging, error shaping, pagination
āāā instructions.py # instructions sent to the client on initialize
āāā annotations.py # MCP tool annotations (read-only / destructive)
āāā endpoint_index.py # loads and searches endpoints.json
āāā endpoints.json # generated index of all 294 endpoints
āāā diffs.py # unified-diff slicing
āāā tools/
āāā generic.py # bb_list_endpoints / bb_request
āāā pr_review.py # curated review tools
āāā pullrequests.py
āāā repositories.py
āāā source.py
āāā issues.py
scripts/generate_endpoints.py # rebuilds endpoints.json from Atlassian's spec
tests/ # 3 offline suites + 1 credential-gated suiteBuilt on MCPServer from the official MCP Python SDK (mcp>=2.1.1) ā the
high-level API formerly called FastMCP, renamed in SDK v2. Tool schemas are
derived from type hints rather than hand-written, ToolError carries readable
failures back to the model, and MCPServer.run owns the stdio transport and the
initialize handshake.
Because stdout is the MCP transport, nothing may be printed there ā diagnostics
go to stderr. tests/test_stdio_handshake.py spawns the server as a real
subprocess and asserts every stdout line is parseable JSON, because a broken
entry point is invisible to in-process tests.
MIT.
Copyright (c) 2025 Kevin Kreger (Kallows) for the original work, and copyright (c) 2026 Mohit Goel for the modifications.
This project combines concepts and code from several open-source projects:
Kallows/mcp-bitbucket by Kevin Kreger ā the original Bitbucket MCP server (MIT License). It established the tool surface this still builds on, and the upstream tool names are retained for compatibility. Thank you for publishing it.
MCP Python SDK ā
server framework, transport and the MCPServer tool API (MIT License).
Atlassian Bitbucket Cloud OpenAPI specification
ā the source the bundled 294-endpoint index in endpoints.json is generated
from, which is why it cannot drift from the published docs.
Migrated from the low-level Server SDK API ā hand-written JSON schemas and a
single call_tool dispatch ā to MCPServer, with schemas derived from typed
signatures.
Split one 856-line module into focused modules with a shared HTTP layer.
Added the generated 294-endpoint index and the bb_list_endpoints /
bb_request pair, taking coverage from 10 endpoints to the whole API.
Added the pull request review toolset, per-file diff handling, and response trimming.
Added workspace/repo auto-detection from the git remote, scoped-token auth, redacted request logging, pagination, tool annotations and the safety switches.
Contributions are welcome. Please:
Open an issue first for anything substantial.
Keep the offline test suites green, and add tests for new behaviour.
Run ruff check . and ruff format ..
Update the README when you change a tool's surface or an env variable.
Create a new branch in a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| branch | Yes | Name for the new branch | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace; '~' targets your personal workspace | |
| start_point | No | Branch or commit to create from | main |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the mutating action and adds no behavioral context beyond the annotations, such as failure on duplicate branches, required write permissions, or side effects of the default start_point. It does not contradict the annotations, but it contributes little beyond them.
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, compact sentence that front-loads the core action and object with no filler. It earns its place without 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 straightforward creation tool with a 100%-described schema and an output schema, the description is mostly sufficient. The only real gap is the absence of when-to-use guidance, which is minor for such a simple 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?
Schema description coverage is 100%, so the schema already documents all four parameters and defaults. The description adds no extra parameter meaning, which places it at the baseline for high 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 names a specific verb and resource: creating a branch in a Bitbucket repository. This clearly separates it from sibling tools like bb_create_repository and bb_create_pull_request. The purpose is immediately understandable.
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 prefer this tool over alternatives or when not to use it. The description relies entirely on the tool name and the agent's inference from the sibling list, and no prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an issue in a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Issue kind | task |
| title | Yes | Issue title | |
| content | No | Issue body (markdown) | |
| priority | No | Issue priority | minor |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the 'create' action is consistent. However, the description adds no extra behavioral context such as authentication needs, rate limits, or side effects. Since annotations already cover the basic safety profile, the description provides little additional value.
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 redundancy. It is appropriately front-loaded and does not waste words, though it is minimal to the point of being sparse.
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 tool with six parameters (one required) and an output schema, the description is thin. It does not mention the repo detection default (though that is in the schema) or any expected return behavior. The schema fills some gaps, but the description could provide more context for an agent to decide when and how to use it.
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 all six parameters are fully documented in the schema. The description itself adds no parameter-level details, which is acceptable given the schema's thoroughness. This matches the baseline of 3.
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 clear verb ('create') and resource ('an issue in a Bitbucket repository'), which distinguishes it from sibling tools like bb_create_pull_request. It is specific enough for an agent to understand the core action, though it does not mention the repository context beyond the generic phrase.
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?
There is no guidance on when to use this tool versus alternatives such as bb_create_pull_request or bb_create_branch. The description does not mention any prerequisites, typical use cases, or conditions that would make this the preferred choice.
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 in a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Pull request title | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| description | No | Pull request description | |
| source_branch | Yes | Branch containing the changes | |
| destination_branch | No | Branch to merge into | main |
| close_source_branch | No | Delete the source branch on merge |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavior beyond the annotations: it only restates the core operation. It fails to disclose side effects such as creating a remote pull request, the default close_source_branch=true behavior that deletes the source branch on merge, or any required authentication/permissions.
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 sentence with no filler, front-loaded with the core action and object. It is appropriately concise for a simple creation tool.
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 output schema and 100% parameter coverage, the description is minimally sufficient for basic invocation, but it leaves out usage context and behavioral side effects. It is adequate but not complete for a mutation tool with 7 parameters.
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 seven parameters and their defaults. The description adds no parameter-specific meaning, and the baseline 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 clearly states the action (create) and the resource (a new pull request in a Bitbucket repository), distinguishing it from siblings like bb_create_repository and bb_create_branch. The specificity of 'pull request' also separates it from read/list PR tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when creating a PR instead of an issue or branch is appropriate, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new repository in Bitbucket
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Repository name | |
| workspace | No | Bitbucket workspace; '~' targets your personal workspace | |
| has_issues | No | Enable the issue tracker | |
| is_private | No | Keep the repository private | |
| description | No | Repository description | |
| project_key | No | Project key; required for workspace repos |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false, so this is understood to be a mutating, non-idempotent operation. The description adds no extra behavioral context beyond that, such as whether creating a repository with an existing name fails, whether it interacts with issues/private defaults, or what access is required. With annotations present, a 3 is reasonable but the description could add more.
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, appropriately brief. However, it is the minimum viable statement: it doesn't add any contextual information beyond the tool name and resource. It is concise but lacks enriching detail that would make it more helpful.
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 all parameters and there is an output schema, the description is functionally sufficient. However, it doesn't communicate important context such as how the workspace and project_key interplay, the fact that '~' targets personal workspace (already in the schema), or any constraints like naming rules. It is adequate but not 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%, so parameters are already well documented in the schema. The description itself adds no parameter-level detail. Baseline 3 applies since schema carries the load; no additional value is provided by the description.
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: 'Create a new repository in Bitbucket.' This clearly differs from sibling tools like bb_create_branch or bb_create_issue. However, it lacks detail about workspace/project context that would help distinguish from other create-family tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or alternatives. However, the tool name and description naturally imply its use case: creating a new repository. The workspace and project_key parameter descriptions hint at the required context, but no explicit guidance is given about when to use this vs. other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file from a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to delete | |
| branch | No | Branch to commit to | main |
| message | No | Commit message | Delete file via MCP |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true and readOnlyHint=false, so the description does not need to restate the safety profile. However, it adds no context about the tool's commit behavior (e.g., that a commit is created on the specified branch) or permission requirements. The description merely restates the operation without enriching the behavioral picture beyond what annotations and schema parameters imply.
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 states the action and target immediately. It contains no filler or redundant words, making it easy for an agent to parse quickly.
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 a simple action, destructive annotations, and a fully documented schema, the description covers the basics. However, it omits the fact that deletion is performed via a commit on a branch, which is a meaningful behavioral detail for an agent deciding whether to call this tool. The branch and message parameters hint at commit semantics, but the description itself does not confirm it, leaving a small but real completeness 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?
All five parameters have schema descriptions, so the schema carries the semantic burden. The tool description does not add any parameter-specific meaning, such as how path should be formatted or how repo_slug/workspace are resolved. This meets the baseline expected when schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'a file from a Bitbucket repository', making the operation clear. It does not explicitly differentiate from sibling tools like bb_write_file, but the name and resource make the 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 offers no guidance on when to use this tool versus alternatives. It does not mention that it should be used instead of bb_write_file for removing files, nor does it specify any preconditions like the repository being available locally. This leaves the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an issue from a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description merely restates the basic delete action without adding behavioral context. It does not disclose whether deletion is permanent, whether associated data is removed, or what failure cases may occur.
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 with no redundancy. It conveys the core operation efficiently and is easy to parse quickly.
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 description is adequate for a destructive tool whose annotations and schema cover the key safety and parameter information, but it lacks guidance on when to use the tool and what the real-world consequences are. The presence of an output schema and full parameter documentation reduces the need to explain return values or arguments.
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 three parameters are documented in the input schema, including defaults for repo_slug and workspace. The description adds no additional parameter context, so the 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 a specific action ('Delete') and a specific resource ('an issue from a Bitbucket repository'). This distinguishes the tool from sibling tools like bb_create_issue and bb_get_pull_request without needing to inspect the schema.
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, nor does it mention any preconditions, such as required permissions or whether the issue must belong to the current repository. Usage context is only implied by the tool name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete diff for every modified file in a pull request in a single call - much more efficient than calling bb_get_pr_file_diff per file
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| include_context | No | Keep diff metadata/context lines |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered by structured metadata. The description adds useful behavioral context beyond the name by emphasizing the single-call aggregation and efficiency advantage over per-file calls. No contradictions with annotations are present.
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, efficient sentence that communicates both the tool's function and its key benefit. It is front-loaded with the core purpose and contains no redundant or filler wording.
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 clear output schema and thoroughly documented parameters, the description is sufficient to guide correct invocation. It could additionally mention cases where per-file diff retrieval might be preferable, but overall the context provided is strong.
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, with each parameter including a clear explanation and relevant defaults. The description adds no additional parameter-level detail, so the schema carries the semantic burden as expected; 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 identifies the action ('Get'), the resource ('the complete diff for every modified file in a pull request'), and the batching benefit over the sibling tool bb_get_pr_file_diff. This makes the tool's purpose unambiguous and easily distinguishable from similar siblings.
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 names bb_get_pr_file_diff as the per-file alternative and states that this tool is 'much more efficient' for multi-file diffs. It gives the agent a clear reason to choose this tool for whole-PR diff retrieval, though it stops short of explicitly saying when to prefer the single-file variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the diffstat for a pull request: every modified file with its added/removed line counts and a totals summary
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds useful behavioral context beyond annotations by specifying exactly what the tool returns: per-file added/removed line counts plus a totals summary. There is no contradiction with annotations, and no hidden side effects are suggested.
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, well-structured sentence that front-loads the core purpose and immediately specifies the output scope. There is no filler, repetition, or unnecessary detail.
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 tool with full schema coverage, an output schema, and clear annotations, the description is complete. It tells the agent what the tool returns and the schema covers all parameter details. Nothing essential is missing for correct invocation.
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 pr_id, repo_slug, and workspace, including the default behavior for repo_slug. The description adds no additional parameter-level semantics, which is acceptable because the schema carries the full burden. A 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 uses a specific verb ('Get') and a specific resource ('diffstat for a pull request'), and further clarifies what a diffstat is: every modified file with added/removed line counts and a totals summary. This distinguishes it clearly from sibling tools like bb_get_pr_file_diff or bb_get_pr_all_file_diffs, which return file content or diffs rather than aggregate counts.
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 when to use this toolāwhen you need summary counts rather than actual diffsābut it never explicitly names alternatives or states when not to use it. With siblings like bb_get_pr_file_diff and bb_get_pr_all_file_diffs present, explicit routing guidance would have made the usage intent unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one file's content at both the source and destination branches of a pull request, for side-by-side review
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| file_path | Yes | Path of the file to fetch | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| include_both | No | Fetch both sides; false fetches only the source |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is covered. The description adds useful behavioral context by specifying that it fetches both branches' content in one call, which is more than a simple single-file read. No contradiction with annotations.
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-structured sentence that front-loads the action and object, then adds branch scope and intended use. Every word earns its place; no repetition 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?
The description, combined with full schema coverage, readOnly/openWorld annotations, and an output schema, provides enough for an agent to select and invoke the tool correctly. The main gap is not explicitly routing away from diff-based siblings, but 'side-by-side review' sufficiently implies the distinction.
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 all five parameters are already documented in structured form. The description adds minimal parameter-specific meaning beyond clarifying the 'both branches' behavior, which maps to include_both. This is an acceptable baseline given the schema's completeness.
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?
Uses a specific verb and resource: 'Get one file's content' at 'both the source and destination branches of a pull request'. This clearly distinguishes it from sibling diff tools like bb_get_pr_file_diff and bb_get_pr_all_file_diffs, which return diffs rather than full file contents.
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 'for side-by-side review' gives clear context for when this tool is appropriate: when both full file versions are needed for comparison. It does not explicitly name alternatives or exclusions, but the dual-branch scope makes the intended use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the line-by-line diff for one specific file in a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| file_path | Yes | Path of the file to diff | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds useful specificity about the result being a line-by-line diff for one file, but does not disclose details such as diff format, hunk context, or whether file metadata is included. This is acceptable because an output schema exists, but the description alone adds only moderate behavioral insight beyond the annotations.
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 with no wasted words. The core action, target resource, and scoping qualifiers are front-loaded, making it easy for an agent to parse and act on quickly.
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 file-diff tool with an output schema and fully documented parameters, the description conveys the essential scope and operation. It is slightly incomplete because it does not explicitly route the agent toward siblings like bb_get_pr_all_file_diffs or bb_get_pr_file_content, but this gap is relatively minor given the clarity of the wording.
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 describes all four parameters with 100% coverage, including defaults for repo_slug and workspace. The description does not add meaningful parameter-level detail beyond reinforcing that file_path targets a single file, so it meets the schema-reliant baseline without exceeding it.
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 identifies a specific verb ('Get'), a clear resource ('line-by-line diff'), and a precise scope ('one specific file in a pull request'). This distinguishes it from siblings like bb_get_pr_all_file_diffs and bb_get_pr_diffstat, 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 implies when to use the tool: when a line-by-line diff of a single file is needed. However, it does not explicitly mention alternatives or state when not to use it, leaving the agent to infer the distinction from sibling tool names rather than receiving direct routing guidance.
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 pull request in a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| include_diff | No | Append the complete diff (can be very large) | |
| include_commits | No | Append the commit list | |
| include_comments | No | Append the comment list |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Get' adds no new behavioral information. It does not mention large diff payloads, default response scope, or any operational caveats, though the schema's include_diff description separately warns about size.
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 with no filler. It is appropriately sized for a simple getter tool.
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 PR fetch with a complete parameter schema, an output schema, and readOnly/openWorld annotations, the short description is almost sufficient. The main missing element is routing guidance among the pull-request-specific sibling tools.
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 fully documents all six parameters and their defaults. The description adds no parameter information, so it stays at the baseline 3.
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 clear verb and resource ('Get details of a pull request') and is readily distinguishable from list/create siblings. It doesn't specify which details are covered, so it's not a 5, but it is specific enough for selection.
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 for when to call this instead of bb_list_pull_requests, bb_get_pr_diffstat, or bb_get_pr_file_content. The intended use is only implied by the verb 'Get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the full Bitbucket Cloud REST API (all endpoints, generated from Atlassian's official OpenAPI spec) to find the right method, path and params for a task. Call this FIRST whenever no purpose-built bb_* tool covers what you need, then pass the result to bb_request. Every whitespace-separated term in search must match, so 'pull request comment' narrows better than 'comment'.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Restrict to one API group, e.g. Pullrequests, Commits, Pipelines, Refs, Source, Search, Workspaces | |
| limit | No | Maximum matches to return | |
| method | No | Restrict to one HTTP method | |
| search | No | Terms matched against id, method, path, tag and summary | |
| verbose | No | Include params, body flag and docs link per match |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers side-effect safety, so the bar is lower. The description reinforces this by describing search/find operations with no mutation language. It also adds context about the source (Atlassian OpenAPI spec), which is helpful. A slight improvement could be an explicit 'does not modify any resources', but not necessary given 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, no filler. It packs purpose, usage context, and a search tip into a tight, well-structured format. The example 'pull request comment' vs 'comment' is concise and effective.
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 discovery tool, the description provides all necessary context: what it does, when to use it, how to use its main parameter, and the downstream step (bb_request). The presence of an output schema means the return value doesn't need to be explained. Everything an agent needs to correctly invoke this tool is covered.
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 all five parameters, so baseline is 3. The main description adds valuable semantics for the `search` parameter (whitespace-separated terms must all match and that using more terms narrows results), which goes beyond the schema 'Terms matched against...'. This extra guidance justifies a 4.
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 searches the full Bitbucket Cloud REST API to find the right method, path, and params. It explicitly differentiates itself from purpose-built siblings by positioning itself as the fallback when no bb_* tool covers the task.
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?
Provides explicit when-to-use guidance ('Call this FIRST whenever no purpose-built bb_* tool covers what you need') and how to integrate with the workflow ('pass the result to bb_request'). Also explains the multi-term AND search behavior with a concrete example, leaving no ambiguity.
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 repository, optionally filtered by state, source or destination branch, or author. Use the source_branch filter to resolve a branch name to its PR number when the user names a branch instead of a PR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum PRs to return | |
| state | No | PR state to list | OPEN |
| author | No | Filter by author nickname or display name substring | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| source_branch | No | Only PRs opened from this branch | |
| destination_branch | No | Only PRs targeting this branch |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint and openWorldHint, so the description's main job is to add behavioral context beyond that. It adds the useful source_branch-to-PR-number resolution behavior and clarifies that results are filterable, which goes beyond the structured annotations without contradicting them.
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-loads the core purpose, and follows with a targeted usage tip. No filler or redundant restatement of the tool name appears.
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 output schema is present, annotations cover read-only and open-world behavior, and all parameters are documented in the schema, the description supplies the one missing contextual clueāhow to bridge from a branch name to a PR number. This is sufficient for a list tool with optional filters.
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 coverage is 100%, so the baseline is 3, but the description adds meaning to the source_branch parameter by explaining its practical role in resolving branch names to PR numbers. This is genuine semantic value beyond the schema's simple field description.
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 identifies the operation as listing pull requests in a repository and enumerates the available filters. It differentiates itself from fetching a single PR by using 'list', but it does not explicitly contrast itself with bb_get_pull_request or other siblings.
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 gives one strong, actionable usage guideline: use the source_branch filter to resolve a branch name to its PR number when the user references a branch instead of a PR. However, it does not state when to prefer an alternative tool such as bb_get_pull_request for single-PR details.
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 as the authenticated user. This is visible to the team - only call it when the user has asked for an approval.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations by noting that the approval is visible to the team. This is a real side-effect that an agent should understand before invoking the tool.
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 short sentences carry the full message with no filler. The core action comes first, and the important usage caveat follows immediately.
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 description is sufficient for a simple, well-documented PR action: it states what it does, when to use it, and a key side-effect. The output schema and parameter descriptions cover the remaining operational detail, though it does not mention potential failure conditions or prerequisites.
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%, and the schema already documents pr_id, repo_slug, and workspace clearly. The description does not add parameter-level detail, so the 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: approve a pull request as the authenticated user. It does not explicitly compare itself to sibling tools like bb_pr_request_changes, but the approve verb makes the 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 gives an explicit usage condition with a strong exclusion: 'only call it when the user has asked for an approval.' This is direct, actionable guidance that prevents inappropriate calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a pull request. Pass file_path and line together to anchor it inline on that line of the diff; pass parent_id to reply within an existing thread; pass neither for a general PR comment.
| Name | Required | Description | Default |
|---|---|---|---|
| line | No | Line number in the new file for an inline comment | |
| pr_id | Yes | Pull request ID | |
| content | Yes | Comment body (markdown) | |
| file_path | No | File to anchor an inline comment to | |
| parent_id | No | Comment ID to reply to | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| on_old_version | No | Anchor the line to the old file instead of the new one |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show this is a mutating, non-destructive operation, and the description aligns. It adds valuable behavior beyond annotations: file_path and line must be paired for inline anchoring, parent_id enables replies, and omitting both creates a general comment.
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 focused sentences with no wasted words. The core action is front-loaded, and the conditional placement rules are compressed into a clear, scannable structure.
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 description covers all three behavioral modes of the tool and the conditions that trigger them. Combined with full schema coverage and an output schema, nothing essential is missing for an agent to invoke 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 coverage is 100%, but the description adds parameter-relationship semantics not visible from individual schemas. It explicitly explains the coupling of file_path and line, the purpose of parent_id, and what happens when neither is supplied.
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?
States a specific verb ('Add a comment') and resource ('pull request'), making the core action unambiguous. It also differentiates itself from sibling tools like bb_pr_list_comments and bb_pr_resolve_thread by being the creation endpoint, and clarifies the three placement modes inline, reply, and general.
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?
Provides clear context for when to use the tool: commenting on a pull request. The description also gives operational guidance for the three comment modes (inline, reply, general), though it does not explicitly mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments on a pull request, showing which are inline (with file and line), which are replies, and which threads are resolved
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| max_pages | No | Comment pages to merge | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| include_resolved | No | Include comments on resolved threads |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description adds meaningful behavior beyond that: comments are classified as inline, replies, and resolved-thread comments. It does not contradict the annotations and provides useful context about the tool's output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then adds only high-value distinguishing detail. There is no filler, repetition, or unnecessary background.
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 read-only annotation, an output schema, and fully documented parameters, the description is complete for selecting and invoking the tool correctly. It explains the key behavioral distinctions an agent needs and does not need to restate schema defaults or return structures.
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 input schema fully documents pr_id, max_pages, repo_slug, workspace, and include_resolved. The description adds no parameter-specific behavior beyond what the schema already states, 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: 'List comments on a pull request', then clearly distinguishes the tool by describing output nuances (inline with file/line, replies, resolved threads). This separates it from sibling comment-related tools like bb_pr_comment and bb_pr_resolve_thread.
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 intended use is implied: use this tool when you need to enumerate PR comments and understand their inline, reply, or resolution status. However, there is no explicit guidance about when not to use it or which sibling tool to prefer for related tasks like posting comments or resolving threads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request changes on a pull request as the authenticated user. Visible to the team - only call it when the user has asked to request changes.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read, non-idempotent mutation. The description adds useful behavior beyond those hints: the action is attributed to the authenticated user and is 'visible to the team,' which tells the agent the call has a visible side effect and should not be made casually.
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 with no filler; the primary purpose is front-loaded and the usage guardrail is stated compactly. Every sentence carries meaning.
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 a complete schema, an output schema, and a clear usage guardrail, the definition is sufficient for a simple PR review action. It could add prerequisites (e.g., open PR, permissions) but these are largely implied and not critical for correct selection.
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 pr_id, repo_slug, and workspace. The description does not add parameter-specific detail, but it does not need to under the baseline for complete 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?
States a specific action ('Request changes') on a specific resource ('a pull request') and adds the agent-scoping condition 'as the authenticated user.' The action is distinct from sibling tools like bb_pr_approve or bb_pr_comment, so an agent can pick it without further schema inspection.
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?
Gives an explicit gate: 'only call it when the user has asked to request changes.' This is a clear when-to-use/exclusion, though it does not name alternatives or describe situations where it should not be used beyond the user-request condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a pull request comment thread as resolved
| Name | Required | Description | Default |
|---|---|---|---|
| pr_id | Yes | Pull request ID | |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace | |
| comment_id | Yes | ID of the thread's root comment |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent, non-destructive operation. The description is accurate but adds little behavioral detail beyond the annotations, such as permission requirements, undo semantics, or side effects.
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 one short, front-loaded sentence with no filler or redundant information. It clearly communicates the tool's purpose without wasting tokens.
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 complete parameter documentation, an output schema, and annotations, the description is sufficient. An agent can invoke this tool correctly based on the description and structured data alone.
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 parameters are already well documented. The description does not add any parameter-level detail, but it also does not need to since the schema covers the meanings of pr_id, repo_slug, workspace, and comment_id.
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 ('Mark') and resource ('pull request comment thread') with a clear target state ('resolved'). It is easy to distinguish from siblings like bb_pr_list_comments or bb_pr_comment because the resolution action is explicitly named.
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: use this tool when a pull request comment thread should be marked resolved. It does not explicitly name alternatives or exclusions, but the action is distinct enough among siblings that an agent can select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file within the repository | |
| branch | No | Branch or commit to read from | main |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what the readOnlyHint annotation already conveys. It does not mention behavior on missing files, binary content, encoding, or which branch/commit is used for resolution, though the schema partially covers the branch parameter. There is no contradiction with the annotations.
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 with no filler or repetition. It states the action and object clearly without redundantly restating schema fields.
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 operation with a fully documented input schema and an existing output schema, the description is mostly sufficient for an agent to invoke the tool correctly. The main gap is lack of routing guidance among sibling file-content tools, but the schema covers invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters meaningfully. The description itself adds no parameter-level detail, so the 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 states a specific verb ('read'), resource ('file'), and container ('Bitbucket repository'), so an agent immediately knows the core operation and that it is not a write or delete tool. However, it does not explicitly differentiate from sibling tools like bb_get_pr_file_content, which also serves file content in a Bitbucket context.
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 when-to-use guidance or alternatives. It does not explain when to choose this over bb_get_pr_file_content or bb_get_pr_file_diff, leaving tool selection mostly to inference from names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call ANY Bitbucket Cloud 2.0 REST endpoint directly. This is the escape hatch for everything the purpose-built bb_* tools do not wrap - merges, commit comparison, branches and tags, pipelines, code search, webhooks, permissions. Use bb_list_endpoints first to get the exact path and params. Paths are relative to https://api.bitbucket.org/2.0 and must have real values substituted for {placeholders}. Set paginate=true on list endpoints to follow Bitbucket's next links and merge all pages.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the response body verbatim instead of pretty-printed JSON (use for diff/patch/log endpoints) | |
| body | No | JSON request body for POST/PUT/PATCH | |
| path | Yes | API path relative to the 2.0 base, e.g. /repositories/myworkspace/myrepo/pullrequests/123/comments | |
| query | No | Query string parameters | |
| method | No | HTTP method | GET |
| paginate | No | GET only: follow `next` links and merge every page's `values` | |
| max_pages | No | Page cap when paginating |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations: it says 'Call ANY Bitbucket Cloud 2.0 REST endpoint' and the schema explicitly allows POST, PUT, DELETE, and PATCH with a request body, yet readOnlyHint is true. This is a serious inconsistency that could cause an agent to believe all requests are safe and non-mutating. The description also does not disclose authentication requirements, rate limits, or that responses may include raw/unprocessed bodies.
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 dense but every sentence earns its place: base URL, placeholder substitution, endpoint discovery via bb_list_endpoints, pagination behavior, and the escape-hatch scope are all covered in five concise sentences. It is front-loaded with the core purpose and avoids repetition of schema fields.
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 generic raw-API tool with an output schema and 100% parameter coverage, the description covers the essential operational details: base path, placeholder substitution, pagination, and how to discover endpoint-specific paths. It could additionally mention authorization preconditions or error/rate-limit behavior, but the existing guidance plus schema is sufficient for most correct calls.
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 meaningful semantics beyond the schema: paths are relative to the 2.0 base URL, placeholders must be replaced with real values, paginate=true follows Bitbucket's next links and merges all pages, and raw mode is relevant for diff/patch/log endpoints. This is solid added value for an agent selecting and invoking parameters.
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 opens with a specific verb and resource: 'Call ANY Bitbucket Cloud 2.0 REST endpoint directly.' It clearly frames the tool as an escape hatch for endpoints not wrapped by purpose-built bb_* tools and enumerates examples (merges, pipelines, webhooks, permissions). This distinguishes it from sibling tools and leaves no ambiguity about what the tool does.
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 gives explicit usage guidance: use it for everything the purpose-built bb_* tools do not wrap, call bb_list_endpoints first to get paths and params, and enable paginate=true on list endpoints. It clearly conveys the fallback role but does not explicitly say to prefer a purpose-built tool when one exists, which is implied but not stated as a negative rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search repositories using Bitbucket's query syntax: name (name ~ "pattern"), project key (project.key = "PROJ"), language (language = "python"), or dates (updated_on >= "2024-01-19", ISO 8601 only). To search file contents instead, use bb_list_endpoints for the code-search endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| query | Yes | Query, e.g. 'name ~ "test"' or 'project.key = "PROJ"' | |
| pagelen | No | Results per page | |
| workspace | No | Bitbucket workspace; '~' targets your personal workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint and openWorldHint already establish that this is a safe read over the open world, and the description adds no further behavioral caveats such as auth requirements, rate limits, ordering, or pagination. The only extra trait is the ISO 8601 date restriction, which is more of a parameter constraint than a behavioral disclosure.
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 with the core verb, query syntax, and alternative mode in the first and second lines; no filler. Front-loaded and easy to scan.
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 search tool with a full input schema, an output schema, and annotations, the description supplies the missing pieces: query-syntax semantics, the ISO date rule, and routing to file-content search. Nothing an agent needs to invoke it correctly is absent.
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?
Because schema coverage is 100%, baseline is 3; the description elevates this by giving representative syntax for four query dimensions and explicitly limiting dates to ISO 8601. It doesn't add information about page/pagelen/workspace, but those are simple and fully documented 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?
States a clear action ('Search repositories') and a specific resource (Bitbucket repositories), with concrete query-syntax examples for names, project keys, languages, and dates. The final sentence explicitly differentiates it from file-content search, so an agent can distinguish it from sibling endpoints.
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?
Provides an explicit conditional: use this tool to search repository metadata; use bb_list_endpoints code-search endpoints instead when the goal is file contents. This is a clear when/when-not pair with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or update a file in a Bitbucket repository
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file within the repository | |
| branch | No | Branch to commit to | main |
| content | Yes | Full new contents of the file | |
| message | No | Commit message | Update file via MCP |
| repo_slug | No | Repository slug/name; defaults to the repo detected from the current directory's git remote | |
| workspace | No | Bitbucket workspace |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a mutating operation, consistent with readOnlyHint=false and destructiveHint=false. However, it adds little beyond the annotations; it does not mention commit behavior, overwrite semantics, or other side effects that could matter to an agent.
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, front-loaded sentence with no filler. Every word contributes to defining the tool's 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?
Given the full parameter schema, output schema, and annotations, the description is largely sufficient for a straightforward write operation. It could be slightly stronger by explicitly noting that the write creates a commit, but the schema already covers branch and commit message defaults.
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 six parameters. The description adds no additional parameter-level meaning or usage detail, keeping this at 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 states a specific action ('Write or update') and a precise resource ('a file in a Bitbucket repository'). It is easily distinguished from sibling tools like bb_read_file and bb_delete_file.
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 used when a file needs to be created or modified in Bitbucket, but it gives no explicit guidance about when not to use it or how it compares to alternative tools for reading or deleting files.
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.
v0.2.0bb_create_branchbb_create_issuebb_create_pull_requestbb_create_repositorybb_delete_filebb_delete_issuebb_get_pr_all_file_diffsbb_get_pr_diffstatbb_get_pr_file_contentbb_get_pr_file_diffbb_get_pull_requestbb_list_endpointsbb_list_pull_requestsbb_pr_approvebb_pr_commentbb_pr_list_commentsbb_pr_request_changesbb_pr_resolve_threadbb_read_filebb_requestbb_search_repositoriesbb_write_fileMost tools map cleanly to a specific resource and action, and the PR comment/review tools are well separated. The only mild concern is the cluster of PR diff/file-content tools (diffstat, file diff, all file diffs, file content), but their descriptions clarify the distinct use cases.
All tools use the bb_ prefix and snake_case with a generally predictable verb_noun structure. Consistency is weakened by switching between 'pull_request' (bb_create_pull_request, bb_list_pull_requests) and the 'pr' abbreviation (bb_get_pr_diffstat, bb_pr_comment, bb_pr_approve).
At 22 tools, the server is on the heavy side and includes several very granular PR diff helpers plus a generic API escape hatch. Each tool has a purpose, but the set feels broader than the typical 3-15 tool sweet spot.
Core workflows around repositories, files, branches, issues, and pull request review are covered, including comments, approvals, and change requests. Some lifecycle operations like updating issues or merging PRs are not purpose-built, but bb_list_endpoints plus bb_request provide a workable escape hatch.
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ā¦
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for siGit (sigit.si): browse repos, search code, manage PRs/issues, web search.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.ā¦
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohitgoel188/mcp-bitbucket'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
