bitbucket-mcp
Related Servers
Alternatives to bitbucket-mcp
No user-submitted related servers found.
Related Servers
- AlicenseBqualityCmaintenanceAn MCP server for Bitbucket Cloud that enables managing pull requests, branches, and repositories in natural language from any MCP-capable client.23186 npm4MIT
- FlicenseAqualityCmaintenanceAn MCP server for Bitbucket Cloud that enables reading and managing pull requests, comments, and descriptions via MCP clients.17-
- AlicenseNot gradedqualityDmaintenanceMCP server for Bitbucket Cloud that enables listing repositories, managing pull requests, posting comments, and handling tasks via natural language.3,208 npmMIT
- AlicenseBqualityDmaintenanceAn MCP server that provides tools for interacting with the Bitbucket API, supporting both Bitbucket Cloud and Bitbucket Server, enabling pull request, branch, file, code review, and search operations.194,121 npmMIT
- FlicenseCqualityCmaintenanceAn MCP server for Bitbucket Cloud, covering pull requests, pull request comments, and pipelines.26-
- AlicenseAqualityCmaintenanceMCP server for Bitbucket Cloud that enables reviewing, managing, and merging pull requests, assigning reviewers by name, reading files at a ref, and inspecting pipeline status from any MCP client.14MIT
TDQS
Scored across 32 tools
Each tool targets a distinct resource and action. Comment tools are differentiated by operation (list/add/inline/reply/edit/delete), and PR views are clearly separated by data type (diff, diffstat, commits, activity, build status). No two tools appear to serve the same purpose.
Most tools follow a verb_noun pattern (list_repos, create_pull_request), but there are notable deviations: data-view tools use a noun-first 'pr_' prefix (pr_diff, pr_commits, pr_activity, pr_build_status) and 'pipeline_steps' lacks a verb. The resource is inconsistently called 'pull_request' in some tools and 'pr' in others, and comment actions use varying prepositions (on, to). Still, the names remain readable and understandable.
At 32 tools, the server exceeds the 'borderline' range of 16-25 and feels heavy. While many tools are justified for a Bitbucket API, there is some overlap (e.g., list_commits vs pr_commits) and the PR comment workflow alone accounts for six tools. The count would be more appropriate if consolidated or scoped tighter, such as focusing on core PR operations.
The pull request lifecycle is thoroughly covered (create, update, approve, merge, decline, comments, diff, commits, activity, build status). However, repository management is incomplete: there is no create/update/delete repo, and branch operations are limited to listing. These are notable gaps for a Bitbucket integration and could force agents to use external tools.