Skip to main content
Glama
deenesjakoruzh
aashari

Atlassian Bitbucket MCP Server

by aashari
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Connect AI to Your Bitbucket Repositories

Transform how you work with Bitbucket by connecting Claude, Cursor AI, and other AI assistants directly to your repositories, pull requests, and code. Get instant insights, automate code reviews, and streamline your development workflow.

NPM Version License

What You Can Do

  • Ask AI about your code: "What's the latest commit in my main repository?"

  • Get PR insights: "Show me all open pull requests that need review"

  • Search your codebase: "Find all JavaScript files that use the authentication function"

  • Review code changes: "Compare the differences between my feature branch and main"

  • Manage pull requests: "Create a PR for my new-feature branch"

  • Automate workflows: "Add a comment to PR #123 with the test results"

Related MCP server: Atlassian Bitbucket MCP Server

Perfect For

  • Developers who want AI assistance with code reviews and repository management

  • Team Leads needing quick insights into project status and pull request activity

  • DevOps Engineers automating repository workflows and branch management

  • Anyone who wants to interact with Bitbucket using natural language

Requirements

  • Node.js 18.0.0 or higher

  • Bitbucket Cloud account (not Bitbucket Server/Data Center)

  • Authentication credentials: Scoped API Token (recommended) or App Password (legacy)

Quick Start

Get up and running in 2 minutes:

1. Get Your Bitbucket Credentials

IMPORTANT: Bitbucket App Passwords are being deprecated and will be removed by June 2026. We recommend using Scoped API Tokens for new setups.

Option A: Scoped API Token (Recommended - Future-Proof)

Bitbucket is deprecating app passwords. Use the new scoped API tokens instead:

  1. Go to Atlassian API Tokens

  2. Click "Create API token with scopes"

  3. Select "Bitbucket" as the product

  4. Choose the appropriate scopes:

    • For read-only access: repository, workspace

    • For full functionality: repository, workspace, pullrequest

  5. Copy the generated token (starts with ATATT)

  6. Use with your Atlassian email as the username

Option B: App Password (Legacy - Will be deprecated)

Generate a Bitbucket App Password (legacy method):

  1. Go to Bitbucket App Passwords

  2. Click "Create app password"

  3. Give it a name like "AI Assistant"

  4. Select these permissions:

    • Workspaces: Read

    • Repositories: Read (and Write if you want AI to create PRs/comments)

    • Pull Requests: Read (and Write for PR management)

2. Try It Instantly

# Set your credentials (choose one method)

# Method 1: Scoped API Token (recommended - future-proof)
export ATLASSIAN_USER_EMAIL="your.email@company.com"
export ATLASSIAN_API_TOKEN="your_scoped_api_token"  # Token starting with ATATT

# OR Method 2: Legacy App Password (will be deprecated June 2026)
export ATLASSIAN_BITBUCKET_USERNAME="your_username"
export ATLASSIAN_BITBUCKET_APP_PASSWORD="your_app_password"

# List your workspaces
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/workspaces"

# List repositories in a workspace
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/repositories/your-workspace"

# Get pull requests for a repository
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/repositories/your-workspace/your-repo/pullrequests"

# Get repository details with JMESPath filtering
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/repositories/your-workspace/your-repo" --jq "{name: name, language: language}"

Connect to AI Assistants

For Claude Desktop Users

Add this to your Claude configuration file (~/.claude/claude_desktop_config.json):

Option 1: Scoped API Token (recommended - future-proof)

{
  "mcpServers": {
    "bitbucket": {
      "command": "npx",
      "args": ["-y", "@aashari/mcp-server-atlassian-bitbucket"],
      "env": {
        "ATLASSIAN_USER_EMAIL": "your.email@company.com",
        "ATLASSIAN_API_TOKEN": "your_scoped_api_token"
      }
    }
  }
}

Option 2: Legacy App Password (will be deprecated June 2026)

{
  "mcpServers": {
    "bitbucket": {
      "command": "npx",
      "args": ["-y", "@aashari/mcp-server-atlassian-bitbucket"],
      "env": {
        "ATLASSIAN_BITBUCKET_USERNAME": "your_username",
        "ATLASSIAN_BITBUCKET_APP_PASSWORD": "your_app_password"
      }
    }
  }
}

Restart Claude Desktop, and you'll see the bitbucket server in the status bar.

For Other AI Assistants

Most AI assistants support MCP. You can either:

Option 1: Use npx (recommended - always latest version): Configure your AI assistant to run: npx -y @aashari/mcp-server-atlassian-bitbucket

Option 2: Install globally:

npm install -g @aashari/mcp-server-atlassian-bitbucket

Then configure your AI assistant to use the MCP server with STDIO transport.

Supported AI assistants:

  • Claude Desktop (official support)

  • Cursor AI

  • Continue.dev

  • Cline

  • Any MCP-compatible client

Alternative: Configuration File

Create ~/.mcp/configs.json for system-wide configuration:

Option 1: Scoped API Token (recommended - future-proof)

{
  "bitbucket": {
    "environments": {
      "ATLASSIAN_USER_EMAIL": "your.email@company.com",
      "ATLASSIAN_API_TOKEN": "your_scoped_api_token",
      "BITBUCKET_DEFAULT_WORKSPACE": "your_main_workspace"
    }
  }
}

Option 2: Legacy App Password (will be deprecated June 2026)

{
  "bitbucket": {
    "environments": {
      "ATLASSIAN_BITBUCKET_USERNAME": "your_username",
      "ATLASSIAN_BITBUCKET_APP_PASSWORD": "your_app_password",
      "BITBUCKET_DEFAULT_WORKSPACE": "your_main_workspace"
    }
  }
}

Alternative config keys: The system also accepts "atlassian-bitbucket", "@aashari/mcp-server-atlassian-bitbucket", or "mcp-server-atlassian-bitbucket" instead of "bitbucket".

Available Tools

This MCP server provides 6 generic tools that can access any Bitbucket API endpoint:

Tool

Description

Parameters

bb_get

GET any Bitbucket API endpoint (read data)

path, queryParams?, jq?, outputFormat?

bb_post

POST to any endpoint (create resources)

path, body, queryParams?, jq?, outputFormat?

bb_put

PUT to any endpoint (replace resources)

path, body, queryParams?, jq?, outputFormat?

bb_patch

PATCH any endpoint (partial updates)

path, body, queryParams?, jq?, outputFormat?

bb_delete

DELETE any endpoint (remove resources)

path, queryParams?, jq?, outputFormat?

bb_clone

Clone a repository locally

workspaceSlug?, repoSlug, targetPath

Tool Parameters

All API tools support these common parameters:

  • path (required): API endpoint path starting with / (the /2.0 prefix is added automatically)

  • queryParams (optional): Key-value pairs for query parameters (e.g., {"pagelen": "25", "page": "2"})

  • jq (optional): JMESPath expression to filter/transform the response - highly recommended to reduce token costs

  • outputFormat (optional): "toon" (default, 30-60% fewer tokens) or "json"

  • body (required for POST/PUT/PATCH): Request body as JSON object

Common API Paths

All paths automatically have /2.0 prepended. Full Bitbucket Cloud REST API 2.0 reference: https://developer.atlassian.com/cloud/bitbucket/rest/

Workspaces & Repositories:

  • /workspaces - List all workspaces

  • /repositories/{workspace} - List repos in workspace

  • /repositories/{workspace}/{repo} - Get repo details

  • /repositories/{workspace}/{repo}/refs/branches - List branches

  • /repositories/{workspace}/{repo}/refs/branches/{branch_name} - Get/delete branch

  • /repositories/{workspace}/{repo}/commits - List commits

  • /repositories/{workspace}/{repo}/commits/{commit} - Get commit details

  • /repositories/{workspace}/{repo}/src/{commit}/{filepath} - Get file content

Pull Requests:

  • /repositories/{workspace}/{repo}/pullrequests - List PRs (GET) or create PR (POST)

  • /repositories/{workspace}/{repo}/pullrequests/{id} - Get/update/delete PR

  • /repositories/{workspace}/{repo}/pullrequests/{id}/diff - Get PR diff

  • /repositories/{workspace}/{repo}/pullrequests/{id}/comments - List/add PR comments

  • /repositories/{workspace}/{repo}/pullrequests/{id}/approve - Approve PR (POST) or remove approval (DELETE)

  • /repositories/{workspace}/{repo}/pullrequests/{id}/request-changes - Request changes (POST)

  • /repositories/{workspace}/{repo}/pullrequests/{id}/merge - Merge PR (POST)

  • /repositories/{workspace}/{repo}/pullrequests/{id}/decline - Decline PR (POST)

Comparisons:

  • /repositories/{workspace}/{repo}/diff/{source}..{destination} - Compare branches/commits

Other Resources:

  • /repositories/{workspace}/{repo}/issues - List/manage issues

  • /repositories/{workspace}/{repo}/downloads - List/manage downloads

  • /repositories/{workspace}/{repo}/pipelines - Access Bitbucket Pipelines

  • /repositories/{workspace}/{repo}/deployments - View deployments

TOON Output Format

What is TOON? Token-Oriented Object Notation is a format optimized for LLMs that reduces token consumption by 30-60% compared to JSON. It uses tabular arrays and minimal syntax while preserving all data.

Default behavior: All tools return TOON format by default. You can override this with outputFormat: "json" if needed.

Example comparison:

JSON (verbose):
{
  "values": [
    {"name": "repo1", "slug": "repo-1"},
    {"name": "repo2", "slug": "repo-2"}
  ]
}

TOON (efficient):
values:
  name  | slug
  repo1 | repo-1
  repo2 | repo-2

Learn more: https://github.com/toon-format/toon

JMESPath Filtering

All tools support optional JMESPath (jq) filtering to extract specific data and reduce token costs further:

Important: Always use jq to filter responses! Unfiltered API responses can be very large and expensive in terms of tokens.

# Get just repository names
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/myworkspace" \
  --jq "values[].name"

# Get PR titles and states (custom object shape)
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/myworkspace/myrepo/pullrequests" \
  --jq "values[].{title: title, state: state, author: author.display_name}"

# Get first result only
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/myworkspace" \
  --jq "values[0]"

# Explore schema with one item first, then filter
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/workspaces" \
  --query-params '{"pagelen": "1"}'

Common JMESPath patterns:

  • values[*].fieldName - Extract single field from all items

  • values[*].{key1: field1, key2: field2} - Create custom object shape

  • values[0] - Get first item only

  • values[:5] - Get first 5 items

  • values[?state=='OPEN'] - Filter by condition

Full JMESPath reference: https://jmespath.org

Real-World Examples

Explore Your Repositories

Ask your AI assistant:

  • "List all repositories in my main workspace"

  • "Show me details about the backend-api repository"

  • "What's the commit history for the feature-auth branch?"

  • "Get the content of src/config.js from the main branch"

Manage Pull Requests

Ask your AI assistant:

  • "Show me all open pull requests that need review"

  • "Get details about pull request #42 including the code changes"

  • "Create a pull request from feature-login to main branch"

  • "Add a comment to PR #15 saying the tests passed"

  • "Approve pull request #33"

Work with Branches and Code

Ask your AI assistant:

  • "Compare my feature branch with the main branch"

  • "List all branches in the user-service repository"

  • "Show me the differences between commits abc123 and def456"

Advanced Usage

Cost Optimization Tips

  1. Always use JMESPath filtering - Extract only needed fields to minimize token usage

  2. Use pagination wisely - Set pagelen query parameter to limit results (e.g., {"pagelen": "10"})

  3. Explore schema first - Fetch one item without filters to see available fields, then filter subsequent calls

  4. Leverage TOON format - Default TOON format saves 30-60% tokens vs JSON

  5. Query parameters for filtering - Use Bitbucket's q parameter for server-side filtering before results are returned

Query Parameter Examples

# Filter PRs by state
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/workspace/repo/pullrequests" \
  --query-params '{"state": "OPEN", "pagelen": "5"}' \
  --jq "values[*].{id: id, title: title}"

# Search PRs by title
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/workspace/repo/pullrequests" \
  --query-params '{"q": "title~\"bug\""}' \
  --jq "values[*].{id: id, title: title}"

# Filter repositories by role
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/workspace" \
  --query-params '{"role": "owner", "pagelen": "10"}'

# Sort by updated date
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/workspace/repo/pullrequests" \
  --query-params '{"sort": "-updated_on"}' \
  --jq "values[*].{id: id, title: title, updated: updated_on}"

Working with Large Responses

When dealing with APIs that return large payloads:

  1. Use sparse fieldsets - Add fields query parameter: {"fields": "values.name,values.slug"}

  2. Paginate results - Use pagelen and page parameters

  3. Filter at the source - Use Bitbucket's q parameter for server-side filtering

  4. Post-process with JQ - Further filter the response with JMESPath

Example combining all techniques:

npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/workspace/repo/pullrequests" \
  --query-params '{"state": "OPEN", "pagelen": "10", "fields": "values.id,values.title,values.state"}' \
  --jq "values[*].{id: id, title: title}"

Best Practices for AI Interactions

  1. Be specific with paths - Use exact workspace/repo slugs (case-sensitive)

  2. Test with CLI first - Verify paths and authentication before using in AI context

  3. Use descriptive JQ filters - Extract meaningful field names for better AI understanding

  4. Enable DEBUG for troubleshooting - See exactly what's being sent to Bitbucket API

  5. Check API limits - Bitbucket Cloud has rate limits; use filtering to reduce calls

CLI Commands

The CLI mirrors the MCP tools for direct terminal access. All commands return JSON output (not TOON - TOON is only for MCP mode).

Available Commands

# Get help
npx -y @aashari/mcp-server-atlassian-bitbucket --help

# GET request
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/workspaces" \
  --jq "values[*].{name: name, slug: slug}"

# GET with query parameters
npx -y @aashari/mcp-server-atlassian-bitbucket get \
  --path "/repositories/myworkspace/myrepo/pullrequests" \
  --query-params '{"state": "OPEN", "pagelen": "10"}' \
  --jq "values[*].{id: id, title: title}"

# POST request (create a PR)
npx -y @aashari/mcp-server-atlassian-bitbucket post \
  --path "/repositories/myworkspace/myrepo/pullrequests" \
  --body '{"title": "My PR", "source": {"branch": {"name": "feature"}}, "destination": {"branch": {"name": "main"}}}' \
  --jq "{id: id, title: title}"

# POST with query parameters
npx -y @aashari/mcp-server-atlassian-bitbucket post \
  --path "/repositories/myworkspace/myrepo/pullrequests/42/comments" \
  --body '{"content": {"raw": "Looks good!"}}' \
  --query-params '{"fields": "id,content"}' \
  --jq "{id: id, content: content.raw}"

# PUT request (replace resource)
npx -y @aashari/mcp-server-atlassian-bitbucket put \
  --path "/repositories/myworkspace/myrepo" \
  --body '{"description": "Updated description", "is_private": true}'

# PATCH request (partial update)
npx -y @aashari/mcp-server-atlassian-bitbucket patch \
  --path "/repositories/myworkspace/myrepo/pullrequests/123" \
  --body '{"title": "Updated PR title"}'

# DELETE request
npx -y @aashari/mcp-server-atlassian-bitbucket delete \
  --path "/repositories/myworkspace/myrepo/refs/branches/old-branch"

# Clone repository
npx -y @aashari/mcp-server-atlassian-bitbucket clone \
  --workspace-slug myworkspace \
  --repo-slug myrepo \
  --target-path /absolute/path/to/parent/directory

CLI Options

For get and delete commands:

  • -p, --path <path> (required) - API endpoint path

  • -q, --query-params <json> (optional) - Query parameters as JSON string

  • --jq <expression> (optional) - JMESPath filter expression

For post, put, and patch commands:

  • -p, --path <path> (required) - API endpoint path

  • -b, --body <json> (required) - Request body as JSON string

  • -q, --query-params <json> (optional) - Query parameters as JSON string

  • --jq <expression> (optional) - JMESPath filter expression

For clone command:

  • --workspace-slug <slug> (optional) - Workspace slug (uses default if not provided)

  • --repo-slug <slug> (required) - Repository slug

  • --target-path <path> (required) - Absolute path to parent directory where repo will be cloned

Debugging

Enable Debug Mode

Set the DEBUG environment variable to see detailed logging:

# For CLI testing
DEBUG=true npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/workspaces"

# For Claude Desktop - add to config
{
  "mcpServers": {
    "bitbucket": {
      "command": "npx",
      "args": ["-y", "@aashari/mcp-server-atlassian-bitbucket"],
      "env": {
        "DEBUG": "true",
        "ATLASSIAN_USER_EMAIL": "...",
        "ATLASSIAN_API_TOKEN": "..."
      }
    }
  }
}

Log files: When running in MCP mode, logs are written to ~/.mcp/data/@aashari-mcp-server-atlassian-bitbucket.[session-id].log

Test with HTTP Mode

For interactive debugging, run the server in HTTP mode and use the MCP Inspector:

# Set credentials first
export ATLASSIAN_USER_EMAIL="your.email@company.com"
export ATLASSIAN_API_TOKEN="your_token"
export DEBUG=true

# Start HTTP server with MCP Inspector
npx -y @aashari/mcp-server-atlassian-bitbucket
# Then in another terminal:
PORT=3000 npm run mcp:inspect

This opens a visual interface to test tools and see request/response data.

Common Issues

Server not appearing in Claude Desktop:

  1. Check config file syntax (valid JSON)

  2. Restart Claude Desktop completely

  3. Check Claude Desktop logs: ~/Library/Logs/Claude/mcp*.log (macOS)

Tools not working:

  1. Enable DEBUG mode to see detailed errors

  2. Test with CLI first to isolate MCP vs credentials issues

  3. Verify API paths are correct (case-sensitive)

Troubleshooting

"Authentication failed" or "403 Forbidden"

  1. Choose the right authentication method:

    • Standard Atlassian method (recommended): Use your Atlassian account email + API token (works with any Atlassian service)

    • Bitbucket-specific method (legacy): Use your Bitbucket username + App password (Bitbucket only)

  2. For Scoped API Tokens (recommended):

    • Go to Atlassian API Tokens

    • Make sure your token is still active and has the right scopes

    • Required scopes: repository, workspace (add pullrequest for PR management)

    • Token should start with ATATT

  3. For Bitbucket App Passwords (legacy):

    • Go to Bitbucket App Passwords

    • Make sure your app password has the right permissions

    • Remember: App passwords will be deprecated by June 2026

  4. Verify your credentials:

    # Test credentials with CLI
export ATLASSIAN_USER_EMAIL="your.email@company.com"
export ATLASSIAN_API_TOKEN="your_token"
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/workspaces"

  5. Environment variable naming:

    • Use ATLASSIAN_USER_EMAIL + ATLASSIAN_API_TOKEN for scoped tokens

    • Use ATLASSIAN_BITBUCKET_USERNAME + ATLASSIAN_BITBUCKET_APP_PASSWORD for app passwords

    • Don't use ATLASSIAN_SITE_NAME - it's not needed for Bitbucket Cloud

"Resource not found" or "404"

  1. Check the API path:

    • Paths are case-sensitive

    • Use workspace slug (from URL), not display name

    • Example: If your repo URL is https://bitbucket.org/myteam/my-repo, use myteam and my-repo

  2. Verify the resource exists:

    # List workspaces to find the correct slug
npx -y @aashari/mcp-server-atlassian-bitbucket get --path "/workspaces"

Claude Desktop Integration Issues

  1. Restart Claude Desktop after updating the config file

  2. Verify config file location:

    • macOS: ~/.claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

Getting Help

If you're still having issues:

  1. Run a simple test command to verify everything works

  2. Check the GitHub Issues for similar problems

  3. Create a new issue with your error message and setup details

Frequently Asked Questions

What permissions do I need?

For Scoped API Tokens (recommended):

  • Required scopes: repository, workspace

  • Add pullrequest for PR management

For Bitbucket App Passwords (legacy):

  • For read-only access: Workspaces: Read, Repositories: Read, Pull Requests: Read

  • For full functionality: Add "Write" permissions for Repositories and Pull Requests

Can I use this with private repositories?

Yes! This works with both public and private repositories. You just need the appropriate permissions through your credentials.

What AI assistants does this work with?

Any AI assistant that supports the Model Context Protocol (MCP):

  • Claude Desktop

  • Cursor AI

  • Continue.dev

  • Many others

Is my data secure?

Yes! This tool:

  • Runs entirely on your local machine

  • Uses your own Bitbucket credentials

  • Never sends your data to third parties

  • Only accesses what you give it permission to access

Migration from v1.x

Version 2.0 represents a major architectural change. If you're upgrading from v1.x:

Before (v1.x) - 20+ specific tools:

bb_ls_workspaces, bb_get_workspace, bb_ls_repos, bb_get_repo,
bb_list_branches, bb_add_branch, bb_get_commit_history, bb_get_file,
bb_ls_prs, bb_get_pr, bb_add_pr, bb_update_pr, bb_approve_pr, bb_reject_pr,
bb_ls_pr_comments, bb_add_pr_comment, bb_diff_branches, bb_diff_commits, bb_search

After (v2.0+) - 6 generic tools:

bb_get, bb_post, bb_put, bb_patch, bb_delete, bb_clone

Migration Examples

v1.x Tool

v2.0+ Equivalent

bb_ls_workspaces()

bb_get(path: "/workspaces")

bb_ls_repos(workspace: "myteam")

bb_get(path: "/repositories/myteam")

bb_get_repo(workspace: "myteam", repo: "myrepo")

bb_get(path: "/repositories/myteam/myrepo")

bb_list_branches(workspace: "myteam", repo: "myrepo")

bb_get(path: "/repositories/myteam/myrepo/refs/branches")

bb_add_branch(...)

bb_post(path: "/repositories/.../refs/branches", body: {...})

bb_ls_prs(workspace: "myteam", repo: "myrepo")

bb_get(path: "/repositories/myteam/myrepo/pullrequests")

bb_get_pr(workspace: "myteam", repo: "myrepo", id: 42)

bb_get(path: "/repositories/myteam/myrepo/pullrequests/42")

bb_add_pr(...)

bb_post(path: "/repositories/.../pullrequests", body: {...})

bb_update_pr(...)

bb_patch(path: "/repositories/.../pullrequests/42", body: {...})

bb_approve_pr(workspace: "myteam", repo: "myrepo", id: 42)

bb_post(path: "/repositories/myteam/myrepo/pullrequests/42/approve", body: {})

bb_diff_branches(...)

bb_get(path: "/repositories/.../diff/branch1..branch2")

Key Changes

  1. All tools now require explicit paths - more verbose but more flexible

  2. Use JMESPath filtering - extract only what you need to reduce tokens

  3. TOON format by default - 30-60% fewer tokens (can override with outputFormat: "json")

  4. Direct Bitbucket API access - any API endpoint works, no code changes needed for new features

Support

Need help? Here's how to get assistance:

  1. Check the troubleshooting section above - most common issues are covered there

  2. Visit our GitHub repository for documentation and examples: github.com/aashari/mcp-server-atlassian-bitbucket

  3. Report issues at GitHub Issues

  4. Start a discussion for feature requests or general questions

Made with care for developers who want to bring AI into their Bitbucket workflow.

Available Tools

6 tools
bb_cloneClone Bitbucket RepositoryA

Clone a Bitbucket repository to your local filesystem using SSH (preferred) or HTTPS.

Provide repoSlug and targetPath (absolute path). Clones into targetPath/repoSlug. SSH keys must be configured; falls back to HTTPS if unavailable.

ParametersJSON Schema
NameRequiredDescriptionDefault
workspaceSlugNoBitbucket workspace slug containing the repository. If not provided, the tool will use your default workspace (either configured via BITBUCKET_DEFAULT_WORKSPACE or the first workspace in your account). Example: "myteam"
repoSlugYesRepository name/slug to clone. This is the short name of the repository. Example: "project-api"
targetPathYesDirectory path where the repository will be cloned. IMPORTANT: Absolute paths are strongly recommended (e.g., "/home/user/projects" or "C:\Users\name\projects"). Relative paths will be resolved relative to the server's working directory, which may not be what you expect. The repository will be cloned into a subdirectory at targetPath/repoSlug. Make sure you have write permissions to this location.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-read-only and non-destructive. Description adds behavioral details like default clone directory and fallback mechanism. No contradictions.

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?

Two concise sentences, front-loaded with core purpose, no redundancy. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers key points for a simple clone operation. No output schema, but return value is likely a confirmation. Could mention error handling (e.g., if path exists), but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%. Description reinforces targetPath behavior (absolute path suggested, subdirectory creation) and optional workspaceSlug usage, adding practical meaning beyond raw schema.

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 explicitly states the action 'Clone a Bitbucket repository' and destination 'local filesystem', distinguishing it from sibling CRUD tools (bb_get, bb_post, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on required parameters (repoSlug, targetPath), path behavior (clones into targetPath/repoSlug), and authentication precedence (SSH preferred, falls back to HTTPS). No explicit when-not-to-use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bb_deleteBitbucket DELETE RequestA
DestructiveIdempotent

Delete Bitbucket resources. Returns TOON format by default.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Delete branch: /repositories/{workspace}/{repo}/refs/branches/{branch_name}

  2. Delete PR comment: /repositories/{workspace}/{repo}/pullrequests/{pr_id}/comments/{comment_id}

  3. Decline PR: /repositories/{workspace}/{repo}/pullrequests/{id}/decline

  4. Remove PR approval: /repositories/{workspace}/{repo}/pullrequests/{id}/approve

  5. Delete repository: /repositories/{workspace}/{repo} (caution: irreversible)

Note: Most DELETE endpoints return 204 No Content on success.

The /2.0 prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Bitbucket API endpoint path (without base URL). Must start with "/". Examples: "/workspaces", "/repositories/{workspace}/{repo_slug}", "/repositories/{workspace}/{repo_slug}/pullrequests/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"pagelen": "25", "page": "2", "q": "state=\"OPEN\"", "fields": "values.title,values.state"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "values[*].{name: name, slug: slug}" (extract specific fields), "values[0]" (first result), "values[*].name" (names only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by noting the default TOON output format, typical 204 No Content response, and the irreversible nature of deleting a repository. These details help the agent understand behavior without contradicting annotations.

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 well-structured with clear sections, front-loaded purpose, and relevant examples. It is concise without being overly terse, though minor repetition ('Returns TOON format by default') could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no output schema), the description adequately covers output format, common operations, and parameter usage. It references an external API documentation link for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description enriches parameters with practical examples (e.g., queryParams, jq expressions, outputFormat enum values) that go beyond the schema's basic descriptions, aiding correct invocation.

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 'Delete Bitbucket resources' and lists specific common operations (delete branch, PR comment, decline PR, etc.), which distinguishes it from sibling tools (bb_get, bb_post, etc.) that have different HTTP methods.

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?

While the description provides a list of common operations and a caution about irreversibility for deleting repositories, it lacks explicit guidance on when to use this tool versus alternatives beyond the implied HTTP method differences.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bb_getBitbucket GET RequestA
Read-onlyIdempotent

Read any Bitbucket data. Returns TOON format by default (30-60% fewer tokens than JSON).

IMPORTANT - Cost Optimization:

  • ALWAYS use jq param to filter response fields. Unfiltered responses are very expensive!

  • Use pagelen query param to restrict result count (e.g., pagelen: "5")

  • If unsure about available fields, first fetch ONE item with pagelen: "1" and NO jq filter to explore the schema, then use jq in subsequent calls

Schema Discovery Pattern:

  1. First call: path: "/workspaces", queryParams: {"pagelen": "1"} (no jq) - explore available fields

  2. Then use: jq: "values[*].{slug: slug, name: name, uuid: uuid}" - extract only what you need

Output format: TOON (default, token-efficient) or JSON (outputFormat: "json")

Common paths:

  • /workspaces - list workspaces

  • /repositories/{workspace} - list repos in workspace

  • /repositories/{workspace}/{repo} - get repo details

  • /repositories/{workspace}/{repo}/pullrequests - list PRs

  • /repositories/{workspace}/{repo}/pullrequests/{id} - get PR details

  • /repositories/{workspace}/{repo}/pullrequests/{id}/comments - list PR comments

  • /repositories/{workspace}/{repo}/pullrequests/{id}/diff - get PR diff

  • /repositories/{workspace}/{repo}/refs/branches - list branches

  • /repositories/{workspace}/{repo}/commits - list commits

  • /repositories/{workspace}/{repo}/src/{commit}/{filepath} - get file content

  • /repositories/{workspace}/{repo}/diff/{source}..{destination} - compare branches/commits

Query params: pagelen (page size), page (page number), q (filter), sort (order), fields (sparse response)

Example filters (q param): state="OPEN", source.branch.name="feature", title~"bug"

JQ examples: values[*].slug, values[0], values[*].{name: name, uuid: uuid}

The /2.0 prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Bitbucket API endpoint path (without base URL). Must start with "/". Examples: "/workspaces", "/repositories/{workspace}/{repo_slug}", "/repositories/{workspace}/{repo_slug}/pullrequests/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"pagelen": "25", "page": "2", "q": "state=\"OPEN\"", "fields": "values.title,values.state"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "values[*].{name: name, slug: slug}" (extract specific fields), "values[0]" (first result), "values[*].name" (names only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds value by detailing default TOON format (token-efficient), automatic /2.0 prefix, and schema discovery pattern. No contradictions. Could mention pagination limits or error responses but still robust.

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?

Well-structured with sections (Important, Schema Discovery, Common paths, etc.) and front-loaded with key guidance. Length is justified by the complexity of the Bitbucket API, but some redundancy in examples could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with no output schema, the description fully compensates by explaining output format, common paths, filters, and a discovery pattern. Covers all practical aspects an agent needs to invoke the tool correctly against Bitbucket API.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds extensive examples (e.g., query param examples, jq expressions, outputFormat enum), providing meaning beyond the schema. More than baseline 3 due to rich contextualization.

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 'Read any Bitbucket data' and emphasizes read-only nature with a list of common paths. It distinguishes from sibling write tools (bb_delete, bb_post, etc.) by specifying reading operations only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit cost optimization guidelines: always use jq filter, use pagelen to limit results, and a schema discovery pattern. Also gives common paths and example filters, leaving no doubt when to use this read tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bb_patchBitbucket PATCH RequestA

Partially update Bitbucket resources. Returns TOON format by default.

IMPORTANT - Cost Optimization: Use jq param to filter response fields.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Update PR title/description: /repositories/{workspace}/{repo}/pullrequests/{id} body: {"title": "New title", "description": "Updated description"}

  2. Update PR reviewers: /repositories/{workspace}/{repo}/pullrequests/{id} body: {"reviewers": [{"uuid": "{user-uuid}"}]}

  3. Update repository properties: /repositories/{workspace}/{repo} body: {"description": "New description"}

  4. Update comment: /repositories/{workspace}/{repo}/pullrequests/{pr_id}/comments/{comment_id} body: {"content": {"raw": "Updated comment"}}

The /2.0 prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Bitbucket API endpoint path (without base URL). Must start with "/". Examples: "/workspaces", "/repositories/{workspace}/{repo_slug}", "/repositories/{workspace}/{repo_slug}/pullrequests/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"pagelen": "25", "page": "2", "q": "state=\"OPEN\"", "fields": "values.title,values.state"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "values[*].{name: name, slug: slug}" (extract specific fields), "values[0]" (first result), "values[*].name" (names only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for PR: {"title": "My PR", "source": {"branch": {"name": "feature"}}}

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds valuable context: default TOON output format, cost optimization via jq param, and examples of common operations. It does not disclose error behavior or permission requirements, but the added details are useful.

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 well-structured with a clear purpose statement, cost optimization note, output format info, and bulleted examples. It is moderately concise but could be trimmed slightly without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters with 100% schema coverage and no output schema, the description covers essential usage patterns and output format. It lacks details on error handling or rate limits, but provides sufficient context for typical PATCH operations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 enhances understanding by providing concrete examples for each parameter (e.g., path examples, queryParams usage, jq expressions, body structures for PR updates). This goes beyond schema definitions.

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 'Partially update Bitbucket resources' and provides specific examples of common operations (e.g., updating PR title, reviewers, repository properties). The verb 'patch' and examples distinguish it effectively from siblings (clone, delete, get, post, put).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for partial updates via examples and contrasts with full updates (PUT) implicitly. However, it lacks explicit guidance on when to use this tool versus alternatives like bb_put, and does not mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bb_postBitbucket POST RequestA

Create Bitbucket resources. Returns TOON format by default (token-efficient).

IMPORTANT - Cost Optimization:

  • Use jq param to extract only needed fields from response (e.g., jq: "{id: id, title: title}")

  • Unfiltered responses include all metadata and are expensive!

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Create PR: /repositories/{workspace}/{repo}/pullrequests body: {"title": "...", "source": {"branch": {"name": "feature"}}, "destination": {"branch": {"name": "main"}}}

  2. Add PR comment: /repositories/{workspace}/{repo}/pullrequests/{id}/comments body: {"content": {"raw": "Comment text"}}

  3. Approve PR: /repositories/{workspace}/{repo}/pullrequests/{id}/approve body: {}

  4. Request changes: /repositories/{workspace}/{repo}/pullrequests/{id}/request-changes body: {}

  5. Merge PR: /repositories/{workspace}/{repo}/pullrequests/{id}/merge body: {"merge_strategy": "squash"} (strategies: merge_commit, squash, fast_forward)

The /2.0 prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Bitbucket API endpoint path (without base URL). Must start with "/". Examples: "/workspaces", "/repositories/{workspace}/{repo_slug}", "/repositories/{workspace}/{repo_slug}/pullrequests/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"pagelen": "25", "page": "2", "q": "state=\"OPEN\"", "fields": "values.title,values.state"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "values[*].{name: name, slug: slug}" (extract specific fields), "values[0]" (first result), "values[*].name" (names only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for PR: {"title": "My PR", "source": {"branch": {"name": "feature"}}}

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses behavioral traits: default TOON format, cost optimization via jq, auto-added /2.0 prefix, and output format options. It aligns with annotations (not read-only, not destructive, not idempotent, open-world hint) and adds significant context beyond structured data.

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 well-structured with a clear purpose statement, important cost optimization note, and a list of common operations. It is slightly verbose but front-loaded with key information, making it efficient for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 5 parameters, nested objects, and no output schema, the description is remarkably complete: it covers output formats, cost optimization, common endpoint patterns, and links to the full API reference. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema description coverage, the description adds substantial meaning: detailed path examples, jq usage with examples, outputFormat benefits, body structure examples for common endpoints. This greatly aids parameter understanding.

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 'Create Bitbucket resources' and provides multiple specific endpoint examples (create PR, add comment, approve, etc.), distinguishing it from sibling tools that handle other HTTP methods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (creating resources) and provides common operations with endpoint and body examples. It lacks explicit when-not-to-use or alternative tool references, but the context signals and sibling tool list imply the usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bb_putBitbucket PUT RequestA
Idempotent

Replace Bitbucket resources (full update). Returns TOON format by default.

IMPORTANT - Cost Optimization:

  • Use jq param to extract only needed fields from response

  • Example: jq: "{uuid: uuid, name: name}"

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Update repository: /repositories/{workspace}/{repo} body: {"description": "...", "is_private": true, "has_issues": true}

  2. Create/update file: /repositories/{workspace}/{repo}/src Note: Use multipart form data for file uploads (complex - prefer PATCH for metadata)

  3. Update branch restriction: /repositories/{workspace}/{repo}/branch-restrictions/{id} body: {"kind": "push", "pattern": "main", "users": [{"uuid": "..."}]}

The /2.0 prefix is added automatically. API reference: https://developer.atlassian.com/cloud/bitbucket/rest/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Bitbucket API endpoint path (without base URL). Must start with "/". Examples: "/workspaces", "/repositories/{workspace}/{repo_slug}", "/repositories/{workspace}/{repo_slug}/pullrequests/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"pagelen": "25", "page": "2", "q": "state=\"OPEN\"", "fields": "values.title,values.state"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "values[*].{name: name, slug: slug}" (extract specific fields), "values[0]" (first result), "values[*].name" (names only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for PR: {"title": "My PR", "source": {"branch": {"name": "feature"}}}

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, describes default TOON output format, automatic /2.0 prefix, and cost optimization behavior. No contradictions 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, but slightly verbose. Front-loaded with purpose and important notes. Could trim some redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main usage patterns and cost optimization. Lacks explicit error handling or response structure details, but examples and reference link partially compensate. Good for a mutation tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters have schema descriptions, and the tool description adds context: path format, jq usage examples, outputFormat enum explanation, and body structure examples. Significantly enhances schema.

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?

Clearly states it is for 'Replace Bitbucket resources (full update).' Distinguishes from sibling tools (bb_patch for partial updates) and provides common operation examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using PATCH for metadata when updating files, provides cost optimization tips (jq param), and lists specific common operations with endpoints and request bodies. Clearly guides when and how to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

TDQS

A4.4/5.0
Disambiguation5/5

Each tool corresponds to a distinct HTTP method (or clone operation) with clear purposes: clone for local cloning, delete for deletions, get for reads, patch for partial updates, post for creations, and put for full replacements. There is no overlap.

Naming Consistency5/5

All tools follow a consistent 'bb_<verb>' pattern using HTTP method names (clone, delete, get, patch, post, put). The naming is predictable and uniform.

Tool Count5/5

With 6 tools, the server provides a concise CRUD+L (clone) interface for Bitbucket. This is well-scoped for a MCP server; each tool has a clear role without unnecessary bloat.

Completeness4/5

The tools cover all standard CRUD operations plus cloning. However, specific workflows like merging or approving PRs are handled via generic post/put, which may require agents to construct endpoint paths. A dedicated tool for common composite operations could improve completeness slightly.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Bitbucket MCP Server

    bobmaertz
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to interact with Bitbucket Cloud repositories, allowing users to manage pull requests, comments, tasks, and branches through natural language commands.
    5,033
    1
    MIT

  • bitbucket-mcp

    yunusemregul
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to programmatically manage Bitbucket Cloud resources, including pull requests, repositories, and branches, automating code review workflows.
    189
    MIT

  • bitbucket-mcp

    lawp09
    A
    license
    A
    quality
    A
    maintenance
    Enables AI assistants to manage Bitbucket Cloud repositories, pull requests, pipelines, and code review tasks through natural language.
    74
    3
    MIT

Appeared in Searches

Latest Blog Posts

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/aashari/mcp-server-atlassian-bitbucket'

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