Loading ToolBench
MCP server for interacting with Bitbucket Cloud repositories, pull requests, pipelines, and comments
Server has 13 tools with consistent naming (verb_noun pattern) and complete input schemas using Zod. All tools have descriptions and parameters are typed. However, descriptions are generic (avg ~60 chars, well below the 194-char baseline for A+ tools), lack actionable context, and output schemas are not documented. Error handling is minimal, safeCall() returns raw API errors without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Missing parameter constraints (e.g., page limits, merge strategy validation). Composition is sound but descriptions don't explain WHEN to use each tool or dependencies between them.
Add a comment to a pull request
Reply to an existing comment thread on a pull request
Approve a pull request as the authenticated user
Create a new pull request
Get status and result of a specific pipeline run
Get full details of a pull request
List branches for a repository
Descriptions are too generic and lack actionable context. E.g., 'List branches for a repository' (50 chars) does not explain WHEN to call this vs list_commits, what the output structure is, or whether pagination is required. Baseline for A+ tools is 194 chars with WHAT/WHEN/WHY guidance.
Output schemas are not documented. LLMs cannot plan downstream calls or extract required fields (e.g., does list_pull_requests return pr_id for get_pull_request chaining?). No documentation of pagination structure, field types, or required vs optional fields in responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
List recent commits for a repository or branch
List recent pipeline runs for a repository (sorted by newest first)
List all comments on a pull request
List pull requests for a repository
List all repositories in the configured Bitbucket workspace
Merge a pull request
Error handling is minimal. safeCall() returns raw API errors (e.g., JSON.stringify(err.response.data)) without recovery guidance. LLMs cannot determine if errors are retryable, user-fixable, or fatal. No actionable error messages like 'PR not found. Try list_pull_requests() first.'
No tool annotations despite clear risk stratification. merge_pull_request is IRREVERSIBLE but lacks destructiveHint. approve_pull_request and add_pr_comment are WRITE operations but lack annotations. LLMs cannot distinguish safe from dangerous tools.
Parameter descriptions lack constraints and validation rules. E.g., 'page' parameter has no documented min/max (should be >=1, typical max 100). 'merge_strategy' enum is documented but no guidance on when to use each strategy. No validation of required fields like 'title' in create_pull_request.