What can you do with this server?

The Bitbucket MCP server is a Model Context Protocol interface that enables AI assistants to fully manage Bitbucket Cloud resources: * Workspaces – List workspaces, get details, list projects, and list members. * Repositories – List, get, create, delete, and fork repositories; retrieve file contents and browse source listings. * Pull Requests – List, get, create, update, merge, approve, unapprove, and decline PRs; manage comments (including inline); retrieve diffs. * Branches & Tags – List, get, create, and delete branches and tags. * Commits – List commits, get commit details, and retrieve diffs or diffstats between refs. * Pipelines (CI/CD) – List, get, trigger (including custom), and stop pipelines; inspect steps and logs; configure pipeline enablement; manage pipeline variables (list, get, create, update, delete). * Issues – List, get, create, update, and delete issues; manage comments; vote/unvote and watch/unwatch. * Webhooks – Full CRUD management of repository-level and workspace-level webhooks (URLs, events, secrets, active status). * Output Formats – All tools support json (full), toon (~50% token savings), and compact (~76% token savings) formats. * Authentication – Supports API token, app password (basic auth), and OAuth.

Which integrations are available for this server?

Enables management of Bitbucket Cloud repositories, pull requests, branches, commits, pipelines, issues, and webhooks. Supports workspace and project operations, code reviews, CI/CD pipeline triggers, and issue tracking.

How do I use Bitbucket MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bitbucket MCP list open pull requests in the frontend 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.

de en es ja ko ru zh

Bitbucket MCP

by icy-r

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Bitbucket MCP

npm version License: MIT

A Model Context Protocol (MCP) server for Bitbucket Cloud. Enables AI assistants to manage repositories, pull requests, pipelines, and more.

Installation

Option 1: Using npx (Recommended)

No installation required. Run directly:

npx @icy-r/bitbucket-mcp

Option 2: Global Installation

npm install -g @icy-r/bitbucket-mcp
bitbucket-mcp

Option 3: Local Development

git clone https://github.com/icy-r/bitbucket-mcp.git
cd bitbucket-mcp
pnpm install
pnpm build
node dist/index.js

Related MCP server: Atlassian Bitbucket MCP Server

MCP Client Configuration

Cursor IDE

Add to your Cursor MCP settings (~/.cursor/mcp.json on Windows: %USERPROFILE%\.cursor\mcp.json):

Using npx (Recommended):

{
  "mcpServers": {
    "bitbucket": {
      "command": "npx",
      "args": ["-y", "@icy-r/bitbucket-mcp"],
      "env": {
        "BITBUCKET_AUTH_METHOD": "api_token",
        "BITBUCKET_USER_EMAIL": "your.email@example.com",
        "BITBUCKET_API_TOKEN": "your_api_token"
      }
    }
  }
}

Using local build:

{
  "mcpServers": {
    "bitbucket": {
      "command": "node",
      "args": ["D:\\path\\to\\bitbucket-mcp\\dist\\index.js"],
      "env": {
        "BITBUCKET_AUTH_METHOD": "api_token",
        "BITBUCKET_USER_EMAIL": "your.email@example.com",
        "BITBUCKET_API_TOKEN": "your_api_token"
      }
    }
  }
}

Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "bitbucket": {
      "command": "npx",
      "args": ["-y", "@icy-r/bitbucket-mcp"],
      "env": {
        "BITBUCKET_AUTH_METHOD": "api_token",
        "BITBUCKET_USER_EMAIL": "your.email@example.com",
        "BITBUCKET_API_TOKEN": "your_api_token"
      }
    }
  }
}

Other MCP Clients

The server follows the MCP standard and works with any compatible client. Use the configuration pattern above, adjusting paths as needed for your platform.

Authentication

API Token (Recommended)

Go to Bitbucket API Tokens
Create a new token with the required permissions
Set the environment variables:

BITBUCKET_AUTH_METHOD=api_token
BITBUCKET_USER_EMAIL=your.email@example.com
BITBUCKET_API_TOKEN=your_api_token

App Password

Go to Bitbucket App Passwords
Create a new app password with required permissions
Use basic auth method with your username and app password

Environment Variables

Variable	Description	Required
`BITBUCKET_AUTH_METHOD`	`api_token`, `oauth`, `basic`	Yes
`BITBUCKET_USER_EMAIL`	Your Atlassian email	For api_token
`BITBUCKET_API_TOKEN`	API token	For api_token
`BITBUCKET_USERNAME`	Bitbucket username	For basic auth
`BITBUCKET_APP_PASSWORD`	App password	For basic auth
`BITBUCKET_WORKSPACE`	Default workspace (used when tool call omits `workspace`)	No
`BITBUCKET_OUTPUT_FORMAT`	`json`, `toon`, `compact`	No

Available Tools

Tool	Actions
`bitbucket_workspaces`	list, get, list_projects, list_members
`bitbucket_repositories`	list, get, create, delete, fork, get_file, list_source
`bitbucket_pull_requests`	list, get, create, update, merge, approve, unapprove, decline, list_comments, add_comment, get_diff
`bitbucket_branches`	list_branches, get_branch, create_branch, delete_branch, list_tags, get_tag, create_tag
`bitbucket_commits`	list, get, get_diff, get_diffstat
`bitbucket_pipelines`	list, get, trigger, trigger_custom, stop, list_steps, get_step, get_logs, get_config, set_enabled, list_variables, get_variable, create_variable, update_variable, delete_variable
`bitbucket_issues`	list, get, create, update, delete, list_comments, add_comment, vote, unvote, watch, unwatch
`bitbucket_webhooks`	list, get, create, update, delete, list_workspace, get_workspace, create_workspace, update_workspace, delete_workspace

Output Formats

Control response verbosity with the format parameter:

Format	Description	Token Savings
`json`	Full JSON output	0%
`toon`	Compact TOON format	~50%
`compact`	Essential fields only	~76%

Example usage:

{ "action": "list", "workspace": "my-workspace", "format": "compact" }

Examples

List repositories in a workspace

{
  "action": "list",
  "workspace": "my-workspace"
}

Create a pull request

{
  "action": "create",
  "workspace": "my-workspace",
  "repo_slug": "my-repo",
  "title": "Feature: Add new functionality",
  "source_branch": "feature/new-feature",
  "destination_branch": "main"
}

Trigger a pipeline

{
  "action": "trigger",
  "workspace": "my-workspace",
  "repo_slug": "my-repo",
  "branch_name": "main"
}

Default workspace

Set BITBUCKET_WORKSPACE in your environment to skip the workspace parameter on every tool call:

{ "action": "list", "repo_slug": "my-repo" }

Development

# Clone the repository
git clone https://github.com/icy-r/bitbucket-mcp.git
cd bitbucket-mcp

# Install dependencies
pnpm install

# Build
pnpm build

# Run tests
pnpm test

# Run in development mode (watch)
pnpm dev

# Lint and format
pnpm lint
pnpm format

Requirements

Node.js >= 20.0.0
pnpm (for development)

License

MIT

Available Tools

8 tools

bitbucket_branchesB

Manage Bitbucket branches and tags. Actions:

list_branches: List all branches in a repository
get_branch: Get details of a specific branch
create_branch: Create a new branch from a commit/ref
delete_branch: Delete a branch
list_tags: List all tags in a repository
get_tag: Get details of a specific tag
create_tag: Create a new tag

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	Yes	Repository slug
`branch_name`	No	Branch name
`tag_name`	No	Tag name
`target`	No	Target commit hash or ref for create operations
`message`	No	Tag message (for annotated tags)
`q`	No	Query string to filter results
`sort`	No	Sort field
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.4/5.0

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.

bitbucket_commitsB

Manage Bitbucket commits and diffs. Actions:

list: List commits in a repository
get: Get details of a specific commit
get_diff: Get diff between two refs (e.g., "branch1..branch2" or "commit1..commit2")
get_diffstat: Get diffstat (summary of changes) between two refs

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	Yes	Repository slug
`commit_hash`	No	Commit hash (required for get action)
`revision`	No	Branch name or commit hash to list commits from
`path`	No	Filter commits by file path
`include`	No	Include commits reachable from this ref
`exclude`	No	Exclude commits reachable from this ref
`spec`	No	Diff spec (e.g., "main..feature" or "abc123..def456")
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.4/5.0

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.

bitbucket_issuesB

Manage Bitbucket issue tracking. Actions:

list: List issues in a repository
get: Get details of a specific issue
create: Create a new issue
update: Update an existing issue
delete: Delete an issue
list_comments: List comments on an issue
add_comment: Add a comment to an issue
vote: Vote for an issue
unvote: Remove vote from an issue
watch: Watch an issue for notifications
unwatch: Stop watching an issue

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	Yes	Repository slug
`issue_id`	No	Issue ID (required for most actions except list/create)
`title`	No	Issue title
`content`	No	Issue description or comment content
`state`	No	Issue state
`priority`	No	Issue priority
`kind`	No	Issue type
`assignee`	No	Assignee account UUID (e.g., "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}")
`q`	No	Query string to filter issues
`sort`	No	Sort field
`reporter`	No	Filter by reporter
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.4/5.0

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.

bitbucket_pipelinesA

Manage Bitbucket Pipelines CI/CD. Actions:

list: List pipelines in a repository
get: Get details of a specific pipeline
trigger: Trigger a new pipeline run on a branch
trigger_custom: Trigger a custom pipeline with a specific pattern
stop: Stop a running pipeline
list_steps: List steps of a pipeline
get_step: Get details of a specific step
get_logs: Get logs for a pipeline step
get_config: Get pipeline configuration (enabled status)
set_enabled: Enable or disable pipelines for a repository
list_variables: List pipeline variables
get_variable: Get a specific pipeline variable
create_variable: Create a pipeline variable
update_variable: Update a pipeline variable
delete_variable: Delete a pipeline variable

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	Yes	Repository slug
`pipeline_uuid`	No	Pipeline UUID
`step_uuid`	No	Step UUID
`branch_name`	No	Branch name to trigger pipeline on (required for trigger/trigger_custom)
`pattern`	No	Custom pipeline pattern (for trigger_custom)
`variables`	No	Pipeline variables for trigger
`enabled`	No	Enable or disable pipelines
`variable_uuid`	No	Variable UUID
`key`	No	Variable key
`value`	No	Variable value
`secured`	No	Whether variable is secured
`sort`	No	Sort field
`target_branch`	No	Filter by target branch
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

A3.6/5.0

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.

bitbucket_pull_requestsB

Manage Bitbucket pull requests. Actions:

list: List pull requests in a repository
get: Get pull request details
create: Create a new pull request
update: Update a pull request
merge: Merge a pull request
approve: Approve a pull request
unapprove: Remove approval from a pull request
decline: Decline a pull request
list_comments: List comments on a pull request
add_comment: Add a comment to a pull request
get_diff: Get the diff of a pull request

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	Yes	Repository slug
`pr_id`	No	Pull request ID (required for most actions except list/create)
`state`	No	Filter by state
`q`	No	Query string to filter PRs
`sort`	No	Sort field (e.g., "-created_on")
`title`	No	Pull request title
`description`	No	Pull request description
`source_branch`	No	Source branch name
`destination_branch`	No	Destination branch (default: main branch)
`close_source_branch`	No	Close source branch after merge
`reviewers`	No	List of reviewer UUIDs
`merge_strategy`	No	Merge strategy
`message`	No	Merge commit message
`content`	No	Comment content (markdown supported)
`inline_path`	No	File path for inline comment (requires inline_line)
`inline_line`	No	Line number for inline comment (requires inline_path)
`parent_id`	No	Parent comment ID for replies
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.2/5.0

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.

bitbucket_repositoriesC

Manage Bitbucket repositories. Actions:

list: List repositories in a workspace
get: Get repository details
create: Create a new repository
delete: Delete a repository
fork: Fork a repository
get_file: Get file content from a repository
list_source: List files/directories in a repository path

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	No	Repository slug (required for most actions except list)
`q`	No	Query string to filter repositories
`sort`	No	Sort field (e.g., "-updated_on" for newest first)
`role`	No	Filter by role
`name`	No	Repository display name (for create)
`description`	No	Repository description (for create)
`is_private`	No	Whether repository is private (for create)
`project_key`	No	Project key to associate with (for create)
`new_name`	No	Name for the forked repository
`target_workspace`	No	Target workspace for the fork
`path`	No	File or directory path in the repository
`ref`	No	Git ref (branch, tag, or commit hash)	HEAD
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

C2.7/5.0

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.

bitbucket_webhooksB

Manage Bitbucket webhooks for repositories and workspaces. Actions:

list: List webhooks for a repository
get: Get details of a specific webhook
create: Create a new webhook
update: Update an existing webhook
delete: Delete a webhook
list_workspace: List webhooks for a workspace
get_workspace: Get a workspace webhook
create_workspace: Create a workspace webhook
update_workspace: Update a workspace webhook
delete_workspace: Delete a workspace webhook

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)
`repo_slug`	No	Repository slug (required for repo-level webhooks)
`webhook_uuid`	No	Webhook UUID (required for get/update/delete)
`url`	No	Webhook URL
`description`	No	Webhook description
`active`	No	Whether webhook is active
`events`	No	List of events to trigger webhook (e.g., "repo:push", "pullrequest:created")
`secret`	No	Webhook secret for signature verification
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.2/5.0

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.

bitbucket_workspacesB

Manage Bitbucket workspaces. Actions:

list: List all accessible workspaces
get: Get details of a specific workspace
list_projects: List projects in a workspace
list_members: List members of a workspace

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`workspace`	No	Workspace slug (uses BITBUCKET_WORKSPACE env if omitted; required for get, list_projects, list_members)
`page`	No	Page number for pagination
`pagelen`	No	Results per page (default: 25, max 100)
`format`	No	Output format: json (full), toon (compact tokens), compact (essential fields only)

TDQS

B3.1/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesMay 5, 2026

Changedbitbucket_branches3 fields changed

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace",
-  "repo_slug"
-]New value: +[
+  "action",
+  "repo_slug"
+]

Changedbitbucket_commits3 fields changed

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace",
-  "repo_slug"
-]New value: +[
+  "action",
+  "repo_slug"
+]

Changedbitbucket_issues4 fields changed

changedInput schema / properties / assignee / description

Previous value: -"Assignee username"New value: +"Assignee account UUID (e.g., \"{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\")"

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace",
-  "repo_slug"
-]New value: +[
+  "action",
+  "repo_slug"
+]

Changedbitbucket_pipelines5 fields changed

removedInput schema / properties / branch

Removed value: -{
-  "description": "Branch name to trigger pipeline on",
-  "type": "string"
-}

addedInput schema / properties / branch_name

Added value: +{
+  "description": "Branch name to trigger pipeline on (required for trigger/trigger_custom)",
+  "type": "string"
+}

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace",
-  "repo_slug"
-]New value: +[
+  "action",
+  "repo_slug"
+]

Changedbitbucket_pull_requests5 fields changed

changedInput schema / properties / inline_line / description

Previous value: -"Line number for inline comment"New value: +"Line number for inline comment (requires inline_path)"

changedInput schema / properties / inline_path / description

Previous value: -"File path for inline comment"New value: +"File path for inline comment (requires inline_line)"

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace",
-  "repo_slug"
-]New value: +[
+  "action",
+  "repo_slug"
+]

Changedbitbucket_repositories3 fields changed

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace"
-]New value: +[
+  "action"
+]

Changedbitbucket_webhooks3 fields changed

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted)"

changedInput schema / required

Previous value: -[
-  "action",
-  "workspace"
-]New value: +[
+  "action"
+]

Changedbitbucket_workspaces2 fields changed

changedInput schema / properties / pagelen / description

Previous value: -"Results per page (max 100)"New value: +"Results per page (default: 25, max 100)"

changedInput schema / properties / workspace / description

Previous value: -"Workspace slug (required for get, list_projects, list_members)"New value: +"Workspace slug (uses BITBUCKET_WORKSPACE env if omitted; required for get, list_projects, list_members)"

8 tool updatesv1.0.1Mar 15, 2026
- First observedbitbucket_branches
- First observedbitbucket_commits
- First observedbitbucket_issues
- First observedbitbucket_pipelines
- First observedbitbucket_pull_requests
- First observedbitbucket_repositories
- First observedbitbucket_webhooks
- First observedbitbucket_workspaces

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
saidsef-mcp-github-pr-issue-analyser
ai.smithery
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Version Control Developer Tools Project Management
26
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,803
BuildkiteOAuth
com.buildkite.mcp
The Buildkite MCP server exposes Buildkite product data (pipelines, builds, jobs, and test data) to AI tools, editors, and agents through the Model Context Protocol. It provides capabilities including pipeline creation and management, build monitoring with specialized tools like 'wait_for_build', efficient log querying using Apache Parquet conversion and caching, and OAuth-based authentication for both read-write and read-only access to Buildkite's REST API.
CI/CD & DevOps Monitoring Observability
2

Related MCP Servers

Atlassian Bitbucket MCP
Version Control Developer Tools Project Management
gemyago
A
license
Not graded
quality
C
maintenance
Enables interaction with Bitbucket through the Model Context Protocol, allowing users to manage pull requests, add comments, review code, create tasks, and perform other repository operations using natural language.
Updated 4 months ago (2026-04-29 12:12 UTC)
7
MIT
Atlassian Bitbucket MCP Server
Version Control Developer Tools
RajuSudhar
A
license
B
quality
B
maintenance
Enables AI assistants to interact with Bitbucket Cloud and self-hosted instances for pull request reviews, code search, repository operations, and managing PR comments and approvals.
Updated 7 days ago (2026-09-01 10:55 UTC)
19
GPL 3.0
Bitbucket MCP Server
Version Control Developer Tools
jlromano
A
license
B
quality
D
maintenance
Enables LLMs to interact with Bitbucket repositories to manage pull requests, branches, and commits through the Model Context Protocol. It supports repository operations such as searching code, accessing file contents, and comparing branches using natural language.
Updated a year ago (2025-08-26 13:10 UTC)
16
3,030
MIT
Bitbucket MCP Server
Version Control Code Analysis
dmtr
A
license
Not graded
quality
C
maintenance
Enables interaction with Bitbucket repositories through the Model Context Protocol, supporting code search, repository management, branch creation, pull requests, and more.
Updated 2 months ago (2026-07-09 12:15 UTC)
1
MIT

Appeared in Searches

A server for finding information about Bitbucket, the Git repository hosting service

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