Loading ToolBench
MCP server for Bitbucket Server/Data Center, JIRA, and Confluence with support for both stdio and OAuth 2.1 connector transports. Exposes 58 tools for reading and writing across Bitbucket pull requests, JIRA issues, and Confluence pages with audit logging.
Server exposes 19 tools across Bitbucket, JIRA, and Confluence with consistent naming (verb_noun pattern: bb_*, jira_*, confluence_*). All tools have descriptions (avg ~120 chars, within 10-1024 range). Input schemas present for all tools with parameter types and descriptions. However, output schemas are NOT documented, LLMs cannot predict response structure for chaining. Error handling is minimal; no recovery guidance or actionable error messages visible in code. Parameter descriptions lack format constraints (e.g., 'pr_id' should specify numeric range). No enum constraints on state filters despite fixed valid values (OPEN, DECLINED, MERGED, ALL). Security: credentials injected via env vars (correct), but no audit logging visible for write operations. Composition is sound, tools are single-responsibility and chainable (e.g., bb_list_prs → bb_get_pr → bb_post_comment). Baseline: avg tool description 194 chars (this server ~120), 100% of A+ tools document return types (this server 0%).
Approve a pull request as the authenticated user
Create a new pull request from a source branch to a target branch
Fetch a single pull request by ID with full details including reviewers, description, and merge status
Get the unified diff for a pull request, showing all file changes with context
List branches in a repository with commit metadata
List all comments and inline code review comments on a pull request, including thread resolution status
Output schemas completely undocumented. LLMs cannot predict response structure, forcing them to guess field names for chaining (e.g., after bb_get_pr, what field contains the PR ID for bb_post_comment?). Baseline: 100% of A+ tools document return types.
State/status parameters accept free-form strings instead of enums. 'state' in bb_my_prs, bb_list_prs accepts 'OPEN, DECLINED, MERGED, ALL' but no enum constraint, LLMs may hallucinate 'PENDING', 'CLOSED', etc. Baseline: constrained-input pattern requires enums for fixed value sets.
No error handling guidance in code. Write operations (bb_post_comment, bb_approve_pr, jira_transition_issue, confluence_patch_page) lack recovery hints. If a PR is already approved, what error is returned? Can it be retried? LLMs need actionable error messages.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
List pull requests in a repository with optional filtering by state and author
List pull requests the authenticated user has a role on (reviewer, author, or participant) across all Bitbucket repositories
Post a general comment or inline code review comment on a pull request
Fetch a single Confluence page by ID with full content and metadata
Get the raw storage format (XML-like markup) of a Confluence page for precise editing
Update a Confluence page by replacing its storage format content
Search for Confluence pages and spaces using CQL (Confluence Query Language)
Add a comment to a JIRA issue
Fetch a single JIRA issue by key with full details including description, status, assignee, and linked issues
Get all linked issues for a JIRA issue (blocks, relates to, duplicates, etc.)
Get available state transitions for a JIRA issue (e.g., Open -> In Progress -> Done)
Search for JIRA issues using JQL (JIRA Query Language) with pagination support
Move a JIRA issue to a new state (e.g., from Open to In Progress)
Parameter descriptions lack format/constraint details. 'pr_id' described as 'Pull request ID (numeric)' but no range specified. 'context_lines' defaults to 3 but no min/max bounds. 'max_results' in jira_search caps at 5000 but description doesn't state this hard limit.
No audit logging visible for write operations. Code comments mention 'Audit lines have to be reconcilable against Atlassian's own audit log' but no log statements visible in provided source. Compliance requires tracing who called what tool, when, and with what result.