Loading ToolBench
MCP Server for Bitbucket Cloud
This server defines two tools with complete input schemas and basic descriptions. However, the descriptions are generic and lack actionable guidance for LLM selection. Parameter descriptions are minimal, and there is no documented output schema. The tools lack context about what fields are returned, when to use each tool vs. alternatives, or error recovery paths. Tool naming follows verb_noun convention, but descriptions do not explain prerequisites, side effects, or expected use patterns. No parameter validation guidance is provided, and no error handling strategies are documented.
Get pull request diff from Bitbucket Cloud
Get pull request details from Bitbucket Cloud
Tool descriptions are too generic and lack LLM-optimized guidance. Both tools describe what they do ('Get pull request details') but fail to explain WHEN to call each tool instead of the other, what fields are returned, or expected use patterns. Descriptions should be 50-200 chars with actionable context for selection.
No output schema is documented. The tools return JSON via text content, but the LLM does not know what fields to expect (id, title, state, reviewers, etc.) or their types. This prevents downstream tool chaining and forces the LLM to reason about response structure.
Parameter descriptions are minimal and lack constraint guidance. 'workspace' and 'repo_slug' are self-explanatory, but no description explains allowed formats, typical examples, or dependency rules. The description should state: 'The Bitbucket workspace name (alphanumeric, no spaces). Can be overridden by BITBUCKET_WORKSPACE env var.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
No error handling guidance. The implementation catches Axios errors and returns InternalError codes, but there is no guidance to the LLM about what to do on 404 (PR not found), 401 (invalid token), or timeout. Errors should include recovery hints: 'Pull request not found, check workspace, repo_slug, and pull_request_id.'
No tool composition or chaining guidance. It is unclear when to call get_bb_pull_request vs get_bb_diff. A user intent like 'show me the PR and its changes' requires two calls, but the descriptions do not guide this multi-step pattern.
No idempotency guarantees or side-effect declarations. Both tools are read-only, but the descriptions do not state this. This prevents agents from knowing these calls are safe to retry.