Provides tools for interacting with the Bitbucket API, including pull request lifecycle (get, list, create, update, merge, comment), branch management (list, delete, get), file and directory operations, code review (approve, request changes), code search, and more, supporting both Bitbucket Cloud and Bitbucket Server.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bitbucket MCP Server List open pull requests assigned to me"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides tools for interacting with the Bitbucket API, supporting both Bitbucket Cloud and Bitbucket Server.
get_pull_request - Retrieve detailed information about a pull request
list_pull_requests - List pull requests with filters (state, author, pagination)
create_pull_request - Create new pull requests
update_pull_request - Update PR details (title, description, reviewers, destination branch)
add_comment - Add comments to pull requests (supports replies)
merge_pull_request - Merge pull requests with various strategies
list_pr_commits - List all commits that are part of a pull request
delete_branch - Delete branches after merge
list_branches - List branches with filtering and pagination
delete_branch - Delete branches (with protection checks)
get_branch - Get detailed branch information including associated PRs
list_branch_commits - List commits in a branch with advanced filtering
list_directory_content - List files and directories in a repository path
get_file_content - Get file content with smart truncation for large files
get_pull_request_diff - Get the diff/changes for a pull request
approve_pull_request - Approve a pull request
unapprove_pull_request - Remove approval from a pull request
request_changes - Request changes on a pull request
remove_requested_changes - Remove change request from a pull request
search_code - Search for code across repositories (currently Bitbucket Server only)
Related MCP server: Bitbucket Server MCP
The easiest way to use this MCP server is directly with npx:
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": [
"-y",
"@nexus2520/bitbucket-mcp-server"
],
"env": {
"BITBUCKET_USERNAME": "your-username",
"BITBUCKET_APP_PASSWORD": "your-app-password"
}
}
}
}For Bitbucket Server:
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"args": [
"-y",
"@nexus2520/bitbucket-mcp-server"
],
"env": {
"BITBUCKET_USERNAME": "your.email@company.com",
"BITBUCKET_TOKEN": "your-http-access-token",
"BITBUCKET_BASE_URL": "https://bitbucket.yourcompany.com"
}
}
}
}Clone or download this repository
Install dependencies:
npm installBuild the TypeScript code:
npm run buildThis server uses Bitbucket App Passwords for authentication.
Log in to your Bitbucket account
Navigate to: https://bitbucket.org/account/settings/app-passwords/
Click "Create app password"
Give it a descriptive label (e.g., "MCP Server")
Select the following permissions:
Account: Read
Repositories: Read, Write
Pull requests: Read, Write
Click "Create"
Important: Copy the generated password immediately (you won't be able to see it again!)
node scripts/setup-auth.jsThis will guide you through the authentication setup process.
Add the server to your MCP settings file (usually located at ~/.vscode-server/data/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json):
{
"mcpServers": {
"bitbucket": {
"command": "node",
"args": ["/absolute/path/to/bitbucket-mcp-server/build/index.js"],
"env": {
"BITBUCKET_USERNAME": "your-username",
"BITBUCKET_APP_PASSWORD": "your-app-password"
}
}
}
}Replace:
/absolute/path/to/bitbucket-mcp-server with the actual path to this directory
your-username with your Bitbucket username (not email)
your-app-password with the app password you created
For Bitbucket Server, use:
{
"mcpServers": {
"bitbucket": {
"command": "node",
"args": ["/absolute/path/to/bitbucket-mcp-server/build/index.js"],
"env": {
"BITBUCKET_USERNAME": "your.email@company.com",
"BITBUCKET_TOKEN": "your-http-access-token",
"BITBUCKET_BASE_URL": "https://bitbucket.yourcompany.com"
}
}
}
}Important for Bitbucket Server users:
Use your full email address as the username (e.g., "john.doe@company.com")
This is required for approval/review actions to work correctly
Once configured, you can use the available tools:
{
"tool": "get_pull_request",
"arguments": {
"workspace": "PROJ", // Required - your project key
"repository": "my-repo",
"pull_request_id": 123
}
}Returns detailed information about the pull request including:
Title and description
Author and reviewers
Source and destination branches
Approval status
Links to web UI and diff
Merge commit details (when PR is merged):
merge_commit_hash: The hash of the merge commit
merged_by: Who performed the merge
merged_at: When the merge occurred
merge_commit_message: The merge commit message
Active comments with nested replies (unresolved comments that need attention):
active_comments: Array of active comments (up to 20 most recent top-level comments)
Comment text and author
Creation date
Whether it's an inline comment (with file path and line number)
Nested replies (for Bitbucket Server):
replies: Array of reply comments with same structure
Replies can be nested multiple levels deep
Parent reference (for Bitbucket Cloud):
parent_id: ID of the parent comment for replies
active_comment_count: Total count of unresolved comments (including nested replies)
total_comment_count: Total count of all comments (including resolved and replies)
File changes:
file_changes: Array of all files modified in the PR
File path
Status (added, modified, removed, or renamed)
Old path (for renamed files)
file_changes_summary: Summary statistics
Total files changed
And more...
Search for code across Bitbucket repositories (currently only supported for Bitbucket Server):
// Search in a specific repository
{
"tool": "search_code",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"search_query": "TODO",
"limit": 50
}
}
// Search across all repositories in a workspace
{
"tool": "search_code",
"arguments": {
"workspace": "PROJ",
"search_query": "deprecated",
"file_pattern": "*.java", // Optional: filter by file pattern
"limit": 100
}
}
// Search with file pattern filtering
{
"tool": "search_code",
"arguments": {
"workspace": "PROJ",
"repository": "frontend-app",
"search_query": "useState",
"file_pattern": "*.tsx", // Only search in .tsx files
"start": 0,
"limit": 25
}
}Returns search results with:
File path and name
Repository and project information
Matched lines with:
Line number
Full line content
Highlighted segments showing exact matches
Pagination information
Example response:
{
"message": "Code search completed successfully",
"workspace": "PROJ",
"repository": "my-repo",
"search_query": "TODO",
"results": [
{
"file_path": "src/utils/helper.js",
"file_name": "helper.js",
"repository": "my-repo",
"project": "PROJ",
"matches": [
{
"line_number": 42,
"line_content": " // TODO: Implement error handling",
"highlighted_segments": [
{ "text": " // ", "is_match": false },
{ "text": "TODO", "is_match": true },
{ "text": ": Implement error handling", "is_match": false }
]
}
]
}
],
"total_count": 15,
"start": 0,
"limit": 50,
"has_more": false
}Note: This tool currently only works with Bitbucket Server. Bitbucket Cloud support is planned for a future release.
{
"tool": "list_pull_requests",
"arguments": {
"workspace": "PROJ", // Required - your project key
"repository": "my-repo",
"state": "OPEN", // Optional: OPEN, MERGED, DECLINED, ALL (default: OPEN)
"author": "username", // Optional: filter by author (see note below)
"limit": 25, // Optional: max results per page (default: 25)
"start": 0 // Optional: pagination start index (default: 0)
}
}Returns a paginated list of pull requests with:
Array of pull requests with same details as get_pull_request
Total count of matching PRs
Pagination info (has_more, next_start)
Note on Author Filter:
For Bitbucket Cloud: Use the username (e.g., "johndoe")
For Bitbucket Server: Use the full email address (e.g., "john.doe@company.com")
{
"tool": "create_pull_request",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"title": "Add new feature",
"source_branch": "feature/new-feature",
"destination_branch": "main",
"description": "This PR adds a new feature...", // Optional
"reviewers": ["john.doe", "jane.smith"], // Optional
"close_source_branch": true // Optional (default: false)
}
}{
"tool": "update_pull_request",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"title": "Updated title", // Optional
"description": "Updated description", // Optional
"destination_branch": "develop", // Optional
"reviewers": ["new.reviewer"] // Optional - see note below
}
}Important Note on Reviewers:
When updating a PR without specifying the reviewers parameter, existing reviewers and their approval status are preserved
When providing the reviewers parameter:
The reviewer list is replaced with the new list
For reviewers that already exist on the PR, their approval status is preserved
New reviewers are added without approval status
This prevents accidentally removing reviewers when you only want to update the PR description or title
Add a comment to a pull request, either as a general comment or inline on specific code:
// General comment
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "Great work on this PR!"
}
}
// Inline comment on specific line
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "Consider extracting this into a separate function",
"file_path": "src/utils/helpers.js",
"line_number": 42,
"line_type": "CONTEXT" // ADDED, REMOVED, or CONTEXT
}
}
// Reply to existing comment
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "I agree with this suggestion",
"parent_comment_id": 456
}
}
// Add comment with code suggestion (single line)
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "This variable name could be more descriptive.",
"file_path": "src/utils/helpers.js",
"line_number": 42,
"line_type": "CONTEXT",
"suggestion": "const userAuthenticationToken = token;"
}
}
// Add comment with multi-line code suggestion
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "This function could be simplified using array methods.",
"file_path": "src/utils/calculations.js",
"line_number": 50,
"suggestion_end_line": 55,
"line_type": "CONTEXT",
"suggestion": "function calculateTotal(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n}"
}
}The suggestion feature formats comments using GitHub-style markdown suggestion blocks that Bitbucket can render. When adding a suggestion:
suggestion is required and contains the replacement code
file_path and line_number are required when using suggestions
suggestion_end_line is optional and used for multi-line suggestions (defaults to line_number)
The comment will be formatted with a ````suggestion` markdown block that may be applicable in the Bitbucket UI
The add_comment tool now supports finding line numbers automatically using code snippets. This is especially useful when AI tools analyze diffs and may struggle with exact line numbers:
// Add comment using code snippet
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "This variable name could be more descriptive",
"file_path": "src/components/Button.res",
"code_snippet": "let isDisabled = false",
"search_context": {
"before": ["let onClick = () => {"],
"after": ["setLoading(true)"]
}
}
}
// Handle multiple matches with strategy
{
"tool": "add_comment",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment_text": "Consider extracting this",
"file_path": "src/utils/helpers.js",
"code_snippet": "return result;",
"search_context": {
"before": ["const result = calculate();"],
"after": ["}"]
},
"match_strategy": "best" // Auto-select highest confidence match
}
}Code Snippet Parameters:
code_snippet: The exact code line to find (alternative to line_number)
search_context: Optional context to disambiguate multiple matches
before: Array of lines that should appear before the target
after: Array of lines that should appear after the target
match_strategy: How to handle multiple matches
"strict" (default): Fail with error showing all matches
"best": Auto-select the highest confidence match
Error Response for Multiple Matches (strict mode):
{
"error": {
"code": "MULTIPLE_MATCHES_FOUND",
"message": "Code snippet 'return result;' found in 3 locations",
"occurrences": [
{
"line_number": 42,
"file_path": "src/utils/helpers.js",
"preview": " const result = calculate();\n> return result;\n}",
"confidence": 0.9,
"line_type": "ADDED"
},
// ... more matches
],
"suggestion": "To resolve, either:\n1. Add more context...\n2. Use match_strategy: 'best'...\n3. Use line_number directly"
}
}This feature is particularly useful for:
AI-powered code review tools that analyze diffs
Scripts that automatically add comments based on code patterns
Avoiding line number confusion in large diffs
Note on comment replies:
Use parent_comment_id to reply to any comment (general or inline)
In get_pull_request responses:
Bitbucket Server shows replies nested in a replies array
Bitbucket Cloud shows a parent_id field for reply comments
You can reply to replies, creating nested conversations
Note on inline comments:
file_path: The path to the file as shown in the diff
line_number: The line number as shown in the diff
line_type:
ADDED - For newly added lines (green in diff)
REMOVED - For deleted lines (red in diff)
CONTEXT - For unchanged context lines
The add_comment tool supports multiple scenarios. Here's when and how to use each approach:
1. General PR Comments (No file/line)
Use when: Making overall feedback about the PR
Required params: comment_text only
Example: "LGTM!", "Please update the documentation"
2. Reply to Existing Comments
Use when: Continuing a conversation thread
Required params: comment_text, parent_comment_id
Works for both general and inline comment replies
3. Inline Comments with Line Number
Use when: You know the exact line number from the diff
Required params: comment_text, file_path, line_number
Optional: line_type (defaults to CONTEXT)
4. Inline Comments with Code Snippet
Use when: You have the code but not the line number (common for AI tools)
Required params: comment_text, file_path, code_snippet
The tool will automatically find the line number
Add search_context if the code appears multiple times
Use match_strategy: "best" to auto-select when multiple matches exist
5. Code Suggestions
Use when: Proposing specific code changes
Required params: comment_text, file_path, line_number, suggestion
For multi-line: also add suggestion_end_line
Creates applicable suggestion blocks in Bitbucket UI
Decision Flow for AI/Automated Tools:
1. Do you want to suggest code changes?
→ Use suggestion with line_number
2. Do you have the exact line number?
→ Use line_number directly
3. Do you have the code snippet but not line number?
→ Use code_snippet (add search_context if needed)
4. Is it a general comment about the PR?
→ Use comment_text only
5. Are you replying to another comment?
→ Add parent_comment_idCommon Pitfalls to Avoid:
Don't use both line_number and code_snippet - pick one
Suggestions always need file_path and line_number
Code snippets must match exactly (including whitespace)
REMOVED lines reference the source file, ADDED/CONTEXT reference the destination
{
"tool": "merge_pull_request",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"merge_strategy": "squash", // Optional: merge-commit, squash, fast-forward
"close_source_branch": true, // Optional
"commit_message": "Custom merge message" // Optional
}
}{
"tool": "list_branches",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"filter": "feature", // Optional: filter by name pattern
"limit": 25, // Optional (default: 25)
"start": 0 // Optional: for pagination (default: 0)
}
}Returns a paginated list of branches with:
Branch name and ID
Latest commit hash
Default branch indicator
Pagination info
{
"tool": "delete_branch",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "feature/old-feature",
"force": false // Optional (default: false)
}
}Note: Branch deletion requires appropriate permissions. The branch will be permanently deleted.
{
"tool": "get_branch",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "feature/new-feature",
"include_merged_prs": false // Optional (default: false)
}
}Returns comprehensive branch information including:
Branch details:
Name and ID
Latest commit (hash, message, author, date)
Default branch indicator
Open pull requests from this branch:
PR title and ID
Destination branch
Author and reviewers
Approval status (approved by, changes requested by, pending)
PR URL
Merged pull requests (if include_merged_prs is true):
PR title and ID
Merge date and who merged it
Statistics:
Total open PRs count
Total merged PRs count
Days since last commit
This tool is particularly useful for:
Checking if a branch has open PRs before deletion
Getting an overview of branch activity
Understanding PR review status
Identifying stale branches
Get all commits in a specific branch with advanced filtering options:
// Basic usage - get recent commits
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "feature/new-feature",
"limit": 50 // Optional (default: 25)
}
}
// Filter by date range
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "main",
"since": "2025-01-01T00:00:00Z", // ISO date string
"until": "2025-01-15T23:59:59Z" // ISO date string
}
}
// Filter by author
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "develop",
"author": "john.doe@company.com", // Email or username
"limit": 100
}
}
// Exclude merge commits
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "release/v2.0",
"include_merge_commits": false
}
}
// Search in commit messages
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "main",
"search": "bugfix", // Search in commit messages
"limit": 50
}
}
// Combine multiple filters
{
"tool": "list_branch_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"branch_name": "develop",
"author": "jane.smith@company.com",
"since": "2025-01-01T00:00:00Z",
"include_merge_commits": false,
"search": "feature",
"limit": 100,
"start": 0 // For pagination
}
}Filter Parameters:
since: ISO date string - only show commits after this date
until: ISO date string - only show commits before this date
author: Filter by author email/username
include_merge_commits: Boolean to include/exclude merge commits (default: true)
search: Search for text in commit messages
Returns detailed commit information:
{
"branch_name": "feature/new-feature",
"branch_head": "abc123def456", // Latest commit hash
"commits": [
{
"hash": "abc123def456",
"abbreviated_hash": "abc123d",
"message": "Add new feature implementation",
"author": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"date": "2025-01-03T10:30:00Z",
"parents": ["parent1hash", "parent2hash"],
"is_merge_commit": false
}
// ... more commits
],
"total_count": 150,
"start": 0,
"limit": 25,
"has_more": true,
"next_start": 25,
"filters_applied": {
"author": "john.doe@example.com",
"since": "2025-01-01",
"include_merge_commits": false
}
}This tool is particularly useful for:
Reviewing commit history before releases
Finding commits by specific authors
Tracking changes within date ranges
Searching for specific features or fixes
Analyzing branch activity patterns
Get all commits that are part of a pull request:
{
"tool": "list_pr_commits",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"limit": 50, // Optional (default: 25)
"start": 0 // Optional: for pagination
}
}Returns commit information for the PR:
{
"pull_request_id": 123,
"pull_request_title": "Add awesome feature",
"commits": [
{
"hash": "def456ghi789",
"abbreviated_hash": "def456g",
"message": "Initial implementation",
"author": {
"name": "Jane Smith",
"email": "jane.smith@example.com"
},
"date": "2025-01-02T14:20:00Z",
"parents": ["parent1hash"],
"is_merge_commit": false
}
// ... more commits
],
"total_count": 5,
"start": 0,
"limit": 25,
"has_more": false
}This tool is particularly useful for:
Reviewing all changes in a PR before merging
Understanding the development history of a PR
Checking commit messages for quality
Verifying authorship of changes
Analyzing PR complexity by commit count
Get the diff/changes for a pull request with optional filtering capabilities:
// Get full diff (default behavior)
{
"tool": "get_pull_request_diff",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"context_lines": 5 // Optional (default: 3)
}
}
// Exclude specific file types
{
"tool": "get_pull_request_diff",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"exclude_patterns": ["*.lock", "*.svg", "node_modules/**", "*.min.js"]
}
}
// Include only specific file types
{
"tool": "get_pull_request_diff",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"include_patterns": ["*.res", "*.resi", "src/**/*.js"]
}
}
// Get diff for a specific file only
{
"tool": "get_pull_request_diff",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"file_path": "src/components/Button.res"
}
}
// Combine filters
{
"tool": "get_pull_request_diff",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"include_patterns": ["src/**/*"],
"exclude_patterns": ["*.test.js", "*.spec.js"]
}
}Filtering Options:
include_patterns: Array of glob patterns to include (whitelist)
exclude_patterns: Array of glob patterns to exclude (blacklist)
file_path: Get diff for a specific file only
Patterns support standard glob syntax (e.g., *.js, src/**/*.res, !test/**)
Response includes filtering metadata:
{
"message": "Pull request diff retrieved successfully",
"pull_request_id": 123,
"diff": "..filtered diff content..",
"filter_metadata": {
"total_files": 15,
"included_files": 12,
"excluded_files": 3,
"excluded_file_list": ["package-lock.json", "logo.svg", "yarn.lock"],
"filters_applied": {
"exclude_patterns": ["*.lock", "*.svg"]
}
}
}{
"tool": "approve_pull_request",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123
}
}{
"tool": "request_changes",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"pull_request_id": 123,
"comment": "Please address the following issues..." // Optional
}
}{
"tool": "list_directory_content",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"path": "src/components", // Optional (defaults to root)
"branch": "main" // Optional (defaults to default branch)
}
}Returns directory listing with:
Path and branch information
Array of contents with:
Name
Type (file or directory)
Size (for files)
Full path
Total items count
{
"tool": "get_file_content",
"arguments": {
"workspace": "PROJ",
"repository": "my-repo",
"file_path": "src/index.ts",
"branch": "main", // Optional (defaults to default branch)
"start_line": 1, // Optional: starting line (1-based, use negative for from end)
"line_count": 100, // Optional: number of lines to return
"full_content": false // Optional: force full content (default: false)
}
}Smart Truncation Features:
Automatically truncates large files (>50KB) to prevent token overload
Default line counts based on file type:
Config files (.yml, .json): 200 lines
Documentation (.md, .txt): 300 lines
Code files (.ts, .js, .py): 500 lines
Log files: Last 100 lines
Use start_line: -50 to get last 50 lines (tail functionality)
Files larger than 1MB require explicit full_content: true or line parameters
Returns file content with:
File path and branch
File size and encoding
Content (full or truncated based on parameters)
Line information (if truncated):
Total lines in file
Range of returned lines
Truncation indicator
Last modified information (commit, author, date)
Example responses:
// Small file - returns full content
{
"file_path": "package.json",
"branch": "main",
"size": 1234,
"encoding": "utf-8",
"content": "{\n \"name\": \"my-project\",\n ...",
"last_modified": {
"commit_id": "abc123",
"author": "John Doe",
"date": "2025-01-21T10:00:00Z"
}
}
// Large file - automatically truncated
{
"file_path": "src/components/LargeComponent.tsx",
"branch": "main",
"size": 125000,
"encoding": "utf-8",
"content": "... first 500 lines ...",
"line_info": {
"total_lines": 3500,
"returned_lines": {
"start": 1,
"end": 500
},
"truncated": true,
"message": "Showing lines 1-500 of 3500. File size: 122.1KB"
}
}npm run dev - Watch mode for development
npm run build - Build the TypeScript code
npm start - Run the built server
Authentication errors: Double-check your username and app password
404 errors: Verify the workspace, repository slug, and PR ID
Permission errors: Ensure your app password has the required permissions
MIT
Add a comment to a pull request. Supports: 1) General PR comments, 2) Replies to existing comments, 3) Inline comments on specific code lines (using line_number OR code_snippet), 4) Code suggestions for single or multi-line replacements. For inline comments, you can either provide exact line_number or use code_snippet to auto-detect the line.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | File path for inline comment. Required for inline comments. Example: "src/components/Button.js" (optional) | |
| line_type | No | Type of line: ADDED (green/new lines), REMOVED (red/deleted lines), or CONTEXT (unchanged lines). Default: CONTEXT | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| suggestion | No | Replacement code for a suggestion. Creates a suggestion block that can be applied in Bitbucket UI. Requires file_path and line_number. For multi-line, include newlines in the string (optional) | |
| line_number | No | Exact line number in the file. Use this OR code_snippet, not both. Required with file_path unless using code_snippet (optional) | |
| code_snippet | No | Exact code text from the diff to find and comment on. Use this instead of line_number for auto-detection. Must match exactly including whitespace (optional) | |
| comment_text | Yes | The main comment text. For suggestions, this is the explanation before the code suggestion. | |
| match_strategy | No | How to handle multiple matches when using code_snippet. "strict": fail with detailed error showing all matches. "best": automatically pick the highest confidence match. Default: "strict" | |
| search_context | No | Additional context lines to help locate the exact position when using code_snippet. Useful when the same code appears multiple times (optional) | |
| pull_request_id | Yes | Pull request ID | |
| parent_comment_id | No | ID of comment to reply to. Use this to create threaded conversations (optional) | |
| suggestion_end_line | No | For multi-line suggestions: the last line number to replace. If not provided, only replaces the single line at line_number (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds meaningful context by explaining supported comment types, the auto-detection behavior of code_snippet, and the distinction between single and multi-line suggestions. This goes beyond a simple 'add comment' statement, though it does not mention side effects or error handling (e.g., strict match failures), which are partially covered in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses a numbered list to structure four distinct capabilities. Every sentence adds value without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 params, nested objects, no output schema), the description covers the main functionality and usage patterns well. It lacks explicit guidance on some edge cases or return values, but the schema compensates. The description is complete enough for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for all 13 parameters, including relationships like 'Use this OR code_snippet, not both.' The description adds a high-level synthesis of modes but does not provide additional parameter-level semantics beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Add a comment to a pull request') and enumerates four distinct modes: general comments, replies, inline comments, and code suggestions. This differentiates it from sibling tools like approve_pull_request or request_changes, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for adding comments) and provides guidance on selecting modes (e.g., line_number vs code_snippet). It does not explicitly contrast with alternatives, but the four-mode breakdown gives clear context for choosing among tool features. No exclusions are stated, but the tool's scope is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Approve a pull request' without mentioning state changes, permissions, reversibility, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, achieving excellent conciseness. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description lacks necessary context. It does not explain what happens upon approval, whether the operation is reversible, or what response to expect, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly described. The tool description adds no additional parameter information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'approve' and resource 'pull request', clearly distinguishing it from siblings like 'request_changes' or 'merge_pull_request'. However, it is very terse and could be more explicit about what approving entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as 'request_changes' or 'unapprove_pull_request'. It simply states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new pull request
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the pull request | |
| reviewers | No | Array of reviewer usernames/emails (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| description | No | Description of the pull request (optional) | |
| source_branch | Yes | Source branch name | |
| destination_branch | Yes | Destination branch name (e.g., "main", "master") | |
| close_source_branch | No | Whether to close source branch after merge (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely restates the action without mentioning side effects (e.g., creating a PR in Bitbucket), required permissions, potential failures, or the outcome of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is appropriately front-loaded and concise, though minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is too minimal to provide complete context. It does not explain the expected result, error scenarios, or how this tool fits into the pull request lifecycle beyond the obvious act of creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter semantics, but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new pull request' uses a specific verb and resource, clearly distinguishing the action from sibling tools like update_pull_request or merge_pull_request. However, it lacks any additional detail about scope or context, such as the Bitbucket workspace or repository, which are only found in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The verb 'create' implies a new resource, but the description does not state exclusions (e.g., do not use this to update existing PRs) or mention any prerequisites like branch existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a branch
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force delete even if branch is not merged (optional, default: false) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| branch_name | Yes | Branch name to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to mention that this is a destructive, irreversible operation, the existence of a force flag, or any error conditions. The description adds no behavioral insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. It is appropriately concise, though under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks any mention of safety implications, force behavior, or failure conditions, leaving the agent without sufficient context to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the baseline is 3. The description itself does not add any parameter-related meaning, but the schema fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a branch" clearly states the action and resource, distinguishing it from siblings like get_branch or list_branches. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, any prerequisites (e.g., branch must be merged), or alternatives. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a branch including associated pull requests
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| branch_name | Yes | Branch name to get details for | |
| include_merged_prs | No | Include merged PRs from this branch (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it "gets" information, which implies a read-only operation, but it does not explicitly mention that it has no side effects, nor does it describe what "detailed information" includes or any default behaviors (e.g., whether merged PRs are included by default). The only behavioral hint is the mention of associated PRs, but this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose and includes a relevant detail about PRs. There is no redundant or filler text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description gives a general idea of the response (detailed branch info + associated PRs) but lacks specifics about return shape or edge cases. The explicit mention of "associated pull requests" adds value, yet the vague phrase "detailed information" leaves some uncertainty. Overall, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The description itself does not add parameter-specific meaning, but the schema already fully documents each parameter. Baseline 3 is appropriate since the description does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: "Get detailed information about a branch" and adds a distinguishing detail, "including associated pull requests." This differentiates it from sibling tools like list_branches (which lists branches) and get_pull_request (which gets a single PR). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user needs branch details along with associated PRs, but it does not explicitly state when to use this over alternatives or mention any exclusions. There is no direct guidance like "use list_branches for branch names only," so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get file content from a repository with smart truncation for large files
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Branch name (optional, defaults to default branch) | |
| file_path | Yes | Path to the file (e.g., "src/index.ts") | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| line_count | No | Number of lines to return (optional, default varies by file size) | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| start_line | No | Starting line number (1-based). Use negative for lines from end (optional) | |
| full_content | No | Force return full content regardless of size (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral trait of smart truncation for large files, which adds value beyond the raw schema. However, with no annotations provided, the description carries the full burden and only vaguely references 'smart truncation' without explaining specifics like response formats, binary file handling, or permission requirements. This is partial disclosure, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose and key behavioral aspect. It is front-loaded and contains no filler. Every word contributes value, making it exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the one-sentence description is insufficient for full contextual understanding. It does not explain the truncation mechanism, potential return values, error handling, or how to retrieve full content (despite full_content being a parameter). The tool's behavior remains underspecified, so completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description mentions truncation, which relates to parameters like line_count and full_content, but adds no specific parameter-level meaning beyond what the schema already provides. Thus, it meets the baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches file content from a repository, using the verb 'Get' and specific resource 'file content'. It includes a distinctive feature ('smart truncation for large files') that adds context. While it does not explicitly distinguish from siblings like list_directory_content, the action is unique enough; a 4 is appropriate for clear verb+resource but no explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or conditions. It simply states what the tool does without contextual advice. Since there is no mention of when not to use it or how it compares to other tools, the score is 2 ('no guidance').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a Bitbucket pull request including merge commit information
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates this is a read operation ('Get details') and mentions the inclusion of merge commit information, which is useful context. However, it does not disclose potential errors, authentication requirements, or the exact shape of the response beyond merge commit info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and a key detail. Every word earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three well-documented parameters and no output schema, the description is reasonably complete. It tells the agent what to expect (details including merge commit info). However, it could be more specific about what 'details' encompasses or that it returns the full pull request object, which would provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, covering 100% of the schema. The description itself adds no extra parameter-level meaning, but this is acceptable because the schema already fully documents workspace, repository, and pull_request_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get'), a specific resource ('details of a Bitbucket pull request'), and an explicit detail ('including merge commit information'). It distinguishes this tool from siblings like list_pull_requests (which lists) and update_pull_request (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need details of a single pull request) but does not explicitly state when not to use it or name alternatives. Given sibling tool names, usage context is somewhat implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the diff/changes for a pull request with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Specific file path to get diff for (e.g., "src/index.ts") (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| context_lines | No | Number of context lines around changes (optional, default: 3) | |
| pull_request_id | Yes | Pull request ID | |
| exclude_patterns | No | Array of glob patterns to exclude (e.g., ["*.lock", "*.svg"]) (optional) | |
| include_patterns | No | Array of glob patterns to include (e.g., ["*.res", "src/**/*.js"]) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'optional filtering' but does not explain output format, pagination, how filters interact, or any limitations. This is insufficient for a tool with no supporting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core function and optional filtering without waste. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, a one-sentence description is inadequate. It does not explain what the diff includes, how filters combine, or any edge cases, making the tool harder to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The phrase 'optional filtering' adds general context for the include/exclude and file_path parameters but does not provide syntax or behavioral details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the diff/changes for a pull request with optional filtering.' This uses a specific verb and resource, and distinguishes it from sibling tools like get_pull_request (which likely returns metadata) and get_file_content (which fetches file contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving pull request changes but does not explicitly state when to use this tool versus alternatives. No mention of exclusions or specific circumstances, though the purpose itself suggests the main use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List commits in a branch with detailed information and filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of commits to return (default: 25) | |
| since | No | ISO date string - only show commits after this date (optional) | |
| start | No | Start index for pagination (default: 0) | |
| until | No | ISO date string - only show commits before this date (optional) | |
| author | No | Filter by author email/username (optional) | |
| search | No | Search for text in commit messages (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| branch_name | Yes | Branch name to get commits from | |
| include_merge_commits | No | Include merge commits in results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'detailed information and filtering options' without explaining any behavioral specifics like pagination, ordering, default values for include_merge_commits, or return format. It does not even explicitly state that the operation is read-only beyond the verb 'List'. The description adds little value over the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the primary action. It is appropriately sized for the tool's complexity, though it could be slightly more structured by explicitly listing key filtering capabilities. It earns a 4 for being efficient and avoid unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description is far too brief to provide adequate context. It does not explain return value structure, pagination behavior, default limits (though defaults are in schema), or any special considerations like how merge commits are handled. The description leaves significant gaps for an agent to understand the full behavior and output of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 10 parameters have descriptions), so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides. It mentions 'filtering options' generically, which is already covered by the parameter descriptions for since, until, author, search, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing commits in a branch. It uses a specific verb ('List') and resource ('commits in a branch'), which distinguishes it from siblings like list_pr_commits (in a pull request) and list_branches (listing branches). However, the phrase 'detailed information and filtering options' is somewhat vague and does not explicitly distinguish from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need commits from a specific branch, providing clear context. It does not mention alternatives or exclusions, but the resource and scope are explicit enough that an AI agent can infer when to invoke it. This meets the 'clear context, no exclusions' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List branches in a repository
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of branches to return (default: 25) | |
| start | No | Start index for pagination (default: 0) | |
| filter | No | Filter branches by name pattern (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'list branches' and does not mention pagination behavior, response format, permissions, or any side effects. This is a significant gap for a tool with pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is appropriately sized for a simple list operation, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic list tool, the description is sufficient for an agent to understand what it does. The schema covers all parameters, and while the description does not mention return values, the absence of an output schema makes that less critical. However, the lack of behavioral transparency slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, providing detailed meaning for all five parameters. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List branches in a repository' clearly states the action (list) and the resource (branches), with a scoping location (repository). It is specific enough to distinguish from sibling tools like delete_branch or get_branch, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to list branches in a repository—but it does not explicitly mention alternatives or exclusions. Usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a repository path
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path (optional, defaults to root, e.g., "src/components") | |
| branch | No | Branch name (optional, defaults to default branch) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic read operation ('List') but does not reveal important traits like whether the listing is recursive, includes hidden files, or how permissions are handled. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's full parameter coverage, the description is minimally adequate. However, it lacks details about the return format or any recursive behavior, which would be useful since there is no output schema. It is incomplete in those respects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no extra meaning about parameters beyond what the schema already states, hence it neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('files and directories') within a repository path. It is unambiguous and distinguishes itself from siblings like get_file_content and list_branches by specifying directory listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: it is used to browse repository contents. However, there are no explicit instructions on when to choose this tool over alternatives, such as get_file_content for file retrieval or search_code for queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all commits that are part of a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of commits to return (default: 25) | |
| start | No | Start index for pagination (default: 0) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure but falls short. It does not mention that results are paginated (the schema includes limit and start parameters), nor does it clarify that 'all commits' may be limited by default (max 25). It also fails to specify output format, ordering, or how commits are defined relative to the PR. The word 'all' could mislead users into expecting every commit regardless of pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It avoids unnecessary words or repetition, making it extremely efficient while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (pagination, PR association, no output schema), the description provides minimal context. It does not clarify what 'part of a pull request' means (e.g., commits on the source branch), how pagination is handled, or what fields are returned. The schema covers parameters, but the description lacks behavioral and return-value details, making it insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters, giving 100% coverage. The description adds no semantic value beyond the schema; it does not explain how parameters interact (e.g., that limit and start control pagination). Since schema coverage is high, a baseline score of 3 is appropriate, but the description could have reinforced key parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly and specifically states the tool's function: 'List all commits that are part of a pull request'. It uses a specific verb (list) and a distinct resource (commits within a pull request), which distinguishes it from sibling tools like list_branch_commits or get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it, such as when needing branch commits instead (list_branch_commits), nor does it reference any sibling tools or usage context. The only implication is that it is used for PR commits, but no explicit differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pull requests for a repository with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of PRs to return (default: 25) | |
| start | No | Start index for pagination (default: 0) | |
| state | No | Filter by PR state: OPEN, MERGED, DECLINED, ALL (default: OPEN) | |
| author | No | Filter by author username | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation via 'List', but does not mention default state filtering (OPEN), pagination behavior, or return format. This is minimal and does not expose important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the verb and resource. Every word contributes to the core purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain default behavior, pagination semantics, or what the returned list contains, leaving significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are fully described in the input schema, so the description adds no parameter-level detail beyond the generic note about 'optional filters'. With schema coverage at 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'pull requests', scoped to 'a repository', clearly indicating a multi-item listing operation. It indirectly distinguishes from 'get_pull_request' via the plural form, but does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like get_pull_request, create_pull_request, or merge_pull_request. It only states the basic function with no exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| commit_message | No | Custom merge commit message (optional) | |
| merge_strategy | No | Merge strategy: merge-commit, squash, fast-forward (optional) | |
| pull_request_id | Yes | Pull request ID | |
| close_source_branch | No | Whether to close source branch after merge (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It simply says 'Merge a pull request', but does not state that merging is an irreversible action, what side effects occur (e.g., source branch closing), or whether special permissions are required. The schema hints at some parameters, but the description itself adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and not verbose. It is crisp but lacks substantive content; still, for conciseness alone, it is appropriately sized—though under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with six parameters, no annotations, and no output schema. It fails to explain merge strategies, optional fields, side effects (like source branch deletion), or what happens after the merge. The rich schema cannot compensate for the lack of high-level behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented with descriptions and enum values. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'merge' with a clear resource ('a pull request'), which distinguishes it from sibling tools like create, update, approve, or request changes. However, it lacks any additional context (e.g., platform, scope) beyond the inherent meaning of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like approve_pull_request or update_pull_request. The description does not mention prerequisites, when merging is appropriate, or any caveats about merge strategies or branch deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove change request from a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose side effects (e.g., changing the pull request review status), permissions required, or behavior if no change request exists. This is a mutation tool with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is easily parsed and efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description omits critical context about what 'change request' means in the Bitbucket review workflow, the effect on the PR status, and any preconditions. With no annotations, the tool is under-specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (workspace, repository, pull_request_id) with 100% coverage. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target ('change request from a pull request'), making it distinct from the sibling tool request_changes which adds a change request. The verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, whether a prior change request must exist, or how it fits with approve/unapprove flows. There are no exclusions or alternatives mentioned, leaving the agent to infer usage from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request changes on a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Comment explaining requested changes (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the action without explaining consequences (e.g., whether this blocks merging, creates a review thread, or notifies the author). The mutation effect is implied but not elaborated, which is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It contains no filler, redundancy, or unnecessary detail, making it easy to parse and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimally adequate but lacks behavioral context (e.g., effect on PR state) that would be expected for a mutation tool with no annotations. It answers 'what' but not 'so what' or 'what next', leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all four parameters (workspace, repository, pull_request_id, comment). The description adds no parameter-level details beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request changes') and the resource ('a pull request'), using a specific verb and object. It distinguishes itself from sibling tools like approve_pull_request, unapprove_pull_request, and merge_pull_request by naming a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_comment or update_pull_request. There is no mention of preconditions, typical scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for code across Bitbucket repositories with enhanced context-aware search patterns (currently only supported for Bitbucket Server)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 25) | |
| start | No | Start index for pagination (default: 0) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | No | Repository slug to search in (optional, searches all repos if not specified) | |
| file_pattern | No | File path pattern to filter results (e.g., "*.java", "src/**/*.ts") (optional) | |
| search_query | Yes | The search term or phrase to look for in code (e.g., "variable") | |
| search_context | No | Context to search for: assignment (term=value), declaration (defining term), usage (calling/accessing term), exact (quoted match), or any (all patterns) | |
| include_patterns | No | Additional custom search patterns to include (e.g., ["variable =", ".variable"]) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only hints at 'enhanced context-aware search patterns' without explaining what that means, nor does it disclose read-only nature, result format, pagination behavior, or any side effects. For a search operation, the agent is left guessing about the return payload and exact behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It leads with the primary action and resource, then adds a critical constraint (Bitbucket Server only). Every word is useful and no information is wasted, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description is minimal and does not explain key aspects such as the structure of results, default behavior (e.g., all repositories), or the meaning of 'context-aware' search. It lacks critical context that an agent needs to confidently invoke the tool, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's phrase 'context-aware search patterns' loosely maps to the 'search_context' parameter, but it does not add meaningful parameter-specific information beyond what the schema already provides. It does not clarify usage of parameters like 'file_pattern' or 'include_patterns' further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for code across Bitbucket repositories.' It uses a specific verb ('search'), names the resource ('code' in Bitbucket repositories), and is distinct from sibling tools (which focus on pull requests, branches, and file content). The mention of 'enhanced context-aware search patterns' further specifies its unique capability, though not fully detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching code) and includes an explicit constraint: 'currently only supported for Bitbucket Server.' This helps agents avoid using it for Bitbucket Cloud. However, it does not mention alternatives because no sibling tools offer code search, so the 'when-not' is partially covered by the server restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove approval from a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| pull_request_id | Yes | Pull request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It only states 'Remove approval from a pull request' without disclosing side effects, permissions, behavior when no approval exists, or irreversibility. This is a mutation tool with minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the action and object. It is concise with no repetitive or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation, three required parameters with full schema descriptions, and no output schema, the description is largely complete. It states what the tool does and the schema covers arguments. However, behavioral details (e.g., effect if no approval exists) are absent, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (workspace, repository, pull_request_id) at 100% coverage. The description adds no additional parameter semantics, but none are needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove approval from a pull request' clearly states a specific action (remove approval) and the resource (pull request). It distinguishes itself from siblings like approve_pull_request and remove_requested_changes, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as approve_pull_request or remove_requested_changes. The intended usage is implied by the name and verb, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing pull request. When updating without specifying reviewers, existing reviewers and their approval status will be preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title (optional) | |
| reviewers | No | New list of reviewer usernames/emails. If provided, replaces the reviewer list (preserving approval status for existing reviewers). If omitted, existing reviewers are preserved. (optional) | |
| workspace | Yes | Bitbucket workspace/project key (e.g., "PROJ") | |
| repository | Yes | Repository slug (e.g., "my-repo") | |
| description | No | New description (optional) | |
| pull_request_id | Yes | Pull request ID | |
| destination_branch | No | New destination branch (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a genuinely important behavioral trait—preserving reviewers and approval status when reviewers are not specified—which is valuable beyond the basic update action. However, with no annotations, it does not address permissions, reversibility, or other side effects, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loaded with the primary action and immediately followed by a critical caveat. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description covers the key reviewer preservation nuance but omits other update semantics (e.g., partial vs full update, response shape, prerequisites). The schema fills parameter details, but the tool description is lean for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All seven parameters are already fully described in the input schema (100% coverage), and the tool description essentially repeats the reviewer caveat already present in the schema. It adds no new semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Update an existing pull request') and adds a clarifying behavioral note about reviewer preservation, which helps distinguish it from create_pull_request or merge_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing pull request' clearly signals it is for modifying already-created PRs, and the reviewer caveat gives a concrete usage condition. It does not explicitly mention alternatives like create_pull_request, but the context and sibling tool names make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1add_commentapprove_pull_requestcreate_pull_requestdelete_branchget_branchget_file_contentget_pull_requestget_pull_request_difflist_branch_commitslist_brancheslist_directory_contentlist_pr_commitslist_pull_requestsmerge_pull_requestremove_requested_changesrequest_changessearch_codeunapprove_pull_requestupdate_pull_requestEach tool targets a distinct resource and action: pull request lifecycle (create, update, get, list, merge, approve, unapprove, request/remove changes, comment, diff, commits), branch management (get, list, delete, commits), and file browsing (list directory, get file). No two tools have overlapping purposes, and descriptions clearly differentiate similar-sounding operations like list_branch_commits vs list_pr_commits.
Tool names generally follow a clear verb_noun pattern (e.g., create_pull_request, list_branches, get_file_content). Minor inconsistencies exist: 'list_pr_commits' abbreviates 'pull_request' while other tools use the full term, and 'add_comment' lacks the 'pull_request' qualifier. Overall, the naming is predictable and readable with only small deviations.
With 19 tools, the server is slightly above the ideal 3-15 range but remains well-scoped for a Bitbucket MCP covering repositories, branches, pull requests, and code search. Each tool serves a distinct purpose, and the count is justified by the breadth of PR workflow actions (approve, request changes, comment, merge, diff, etc.). It feels comprehensive rather than bloated.
The tool surface covers most of the core Bitbucket workflows, especially pull requests (create, update, list, get, merge, approve, request changes, comment, diff, commits). However, notable gaps exist: there is no create_branch (only get, list, delete), no decline_pull_request, and no way to edit or commit file content. These missing operations could hinder agents in common scenarios, though many workarounds are possible.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP Server for JFrog, providing tools for development and artifact management.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhanglc/bitbucket-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server