Bitbucket MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool covers a distinct Bitbucket domain (branches, commits, issues, pipelines, pull requests, repositories, webhooks, workspaces) with no overlap in primary functionality. An agent can easily select the correct tool for a task.
Naming Consistency5/5
All tools follow a consistent 'bitbucket_<domain>' pattern, and within each tool, action names are short, clear verbs. The naming scheme is predictable and uniform across the entire set.
Tool Count5/5
With 8 tools covering the major Bitbucket features, the count is well-scoped for the platform's complexity. Each tool represents a natural grouping of related actions, avoiding unnecessary fragmentation or lumping.
Completeness5/5
The tool surface covers all core Bitbucket operations: source control (branches, commits), collaboration (PRs, issues), CI/CD (pipelines), repository management, webhooks, and workspaces. Critical workflows like create/update/delete are present where applicable.
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 22, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose behavioral traits such as whether actions are read-only or destructive (e.g., delete is destructive but not flagged). No information on authentication requirements, rate limits, side effects, or response behavior is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a bullet list of actions. It is front-loaded with 'Manage Bitbucket repositories' and then enumerates actions efficiently. No redundant information is present, but some structure could be improved by grouping actions or adding brief parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, 7 actions, no output schema), the description is incomplete. It does not explain return values, pagination handling, or how the 'action' parameter selects behavior. Missing context on parameter dependencies and result formats leaves agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the tool description adds no meaning beyond the schema; it only lists actions without mapping which parameters apply to each action. For example, 'name' is for create but not indicated. This omission reduces the value, making it harder for agents to understand parameter usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages Bitbucket repositories and lists specific actions like list, get, create, delete. This provides a clear verb+resource mapping for each action. However, it does not explicitly differentiate from sibling tools, though the resource type (repositories) is distinct from branches, commits, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools (e.g., bitbucket_branches, bitbucket_issues). There are no conditions, prerequisites, or alternatives mentioned. The list of actions implies usage but lacks explicit when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not mention behavioral traits such as required permissions, side effects (e.g., mutability), rate limits, or behavior when the workspace parameter is omitted beyond the schema note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses a bullet-style list of actions, making it scannable. Every sentence is relevant, though it could be slightly tighter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what each action returns (e.g., list returns workspace list, get returns workspace details). The absence of return information and examples makes it incomplete for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema descriptions; the workspace parameter's fallback to an environment variable is already in the schema. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Bitbucket workspaces and enumerates four specific actions (list, get, list_projects, list_members), distinguishing it from sibling tools focused on branches, commits, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions but provides no guidance on when to use this tool versus alternatives like bitbucket_repositories or bitbucket_pull_requests, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as side effects (e.g., merge finalizes the PR), required permissions, rate limits, or error handling. The action names imply behavior but lack explicit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences—the first stating the purpose, the second a bullet list of actions. No redundant information, effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (22 parameters, 11 actions), the description lacks behavioral details, usage context, and outcome explanations. The output schema is absent, and the description does not compensate, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond listing actions, achieving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage Bitbucket pull requests' and enumerates 11 specific actions (list, get, create, update, merge, approve, etc.), distinguishing the tool from sibling tools that cover branches, commits, issues, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions but provides no guidance on when to use this tool versus alternatives (e.g., bitbucket_branches for branch management) or when to use specific actions like create vs update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like authentication requirements, side effects of create/update/delete, or pagination behavior. It only lists actions and parameters, failing to add critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the overall purpose. However, the bullet list could be more compact, and it wastes some space repeating actions that are already defined in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 10 actions) and lack of output schema, the description should provide return value expectations or usage patterns for each action. It only lists actions, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description merely duplicates the action enum list without adding any insight into parameter usage, formats, or relationships beyond what the schema provides. It adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage Bitbucket webhooks for repositories and workspaces' and enumerates specific actions. This verb+resource combination distinguishes it from sibling tools which focus on other Bitbucket resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via action listing but provides no explicit guidance on when to use this tool versus alternatives or how to choose between the many actions. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose destructive actions (e.g., delete_branch) as irreversible, nor does it mention required permissions, rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single introductory sentence and a bullet-like list of actions. It is well-structured and front-loaded, though the list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all actions but lacks information on return values, pagination behavior, and parameter applicability per action. Since there is no output schema, the agent needs more context to understand responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds no further parameter-level meaning; it only lists action names. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Bitbucket branches and tags, and lists all 7 specific actions. It distinguishes from sibling tools like bitbucket_commits which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions but provides no explicit guidance on when to use this tool vs siblings, nor does it explain prerequisites or context. Usage is implied by action names only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists actions and gives an example for get_diff, but fails to disclose whether the tool is read-only, authentication requirements, rate limits, or error handling. The word 'Manage' suggests mutation capability but no action modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one introductory sentence and a bullet list of four actions. Each action gets a clear one-line description. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 12 parameters and no output schema, the description does not explain return values, pagination behavior, error scenarios, or output format specifics. The 'format' parameter is listed but not explained in the description. Critical context for a complex tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value by mentioning spec format in the get_diff example, which is already in the schema. No additional parameter guidance is provided beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states managing Bitbucket commits and diffs with four specific actions (list, get, get_diff, get_diffstat). It differentiates from sibling tools like bitbucket_branches by focusing on commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for commits tasks but provides no explicit when-to-use or when-not instructions compared to siblings. The get_diff example gives a hint for usage, but no alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It lists actions but does not disclose behavioral traits like authentication needs, rate limits, side effects (e.g., deletion permanence), or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with a clear front-loaded purpose statement and a bullet list of actions. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the description fails to explain return values, error handling, or how parameters map to specific actions. For a tool with 16 parameters and no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds no extra meaning beyond the schema; it merely restates action names without detailing parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages Bitbucket issue tracking and enumerates all actions (list, get, create, etc.). It differentiates from sibling tools which focus on branches, commits, etc., by targeting issues specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for issue management but lacks context like prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It lists actions and some constraints (e.g., branch_name required for trigger/trigger_custom), but lacks details on side effects, auth needs, rate limits, or idempotency for actions like trigger, stop, and set_enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy due to listing 15 actions, but each line is clear and front-loaded. It could be more concise by grouping similar actions, but overall it is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, many actions), the description covers the actions list but lacks explanation of return values (no output schema), error scenarios, or usage examples. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a brief summary of actions but does not elaborate on parameter meanings beyond what the schema already provides (e.g., variables structure, format options).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists 15 specific sub-actions (list, get, trigger, etc.), each with a clear verb+resource pattern. It clearly distinguishes from sibling tools by focusing exclusively on Bitbucket Pipelines CI/CD management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool (for managing pipelines) but provides no explicit guidance on when to choose one action over another or when not to use this tool compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bitbucket-mcp MCP server](https://glama.ai/mcp/servers/icy-r/bitbucket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/icy-r/bitbucket-mcp)

Score Badge

Copy to your README.md:

[![bitbucket-mcp MCP server](https://glama.ai/mcp/servers/icy-r/bitbucket-mcp/badges/score.svg)](https://glama.ai/mcp/servers/icy-r/bitbucket-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/icy-r/bitbucket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server