Bitbucket MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries. For example, list_pull_requests retrieves a list, get_pull_request gets details, create_pull_request creates new ones, and update_pull_request modifies existing ones. There is no functional overlap between tools like approve_pull_request, request_changes, and remove_requested_changes, which all handle different review states.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case. Verbs like list, get, create, update, delete, add, approve, merge, remove, request, search, and unapprove are used predictably. There are no deviations in naming conventions across the 19 tools.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a comprehensive Bitbucket server covering repositories, branches, pull requests, and code operations. It includes core CRUD and lifecycle management without being excessive, though it borders on the upper limit of typical scopes.
Completeness5/5
The tool set provides complete coverage for Bitbucket operations, including full pull request lifecycle (create, get, list, update, approve, request changes, merge, comment), branch management (list, get, delete), repository navigation (list directory, get file), and code search. No obvious gaps exist for the domain.
Average 3/5 across 19 of 19 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 7 community issues answered or closed in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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. 'Delete a branch' implies a destructive mutation, but it doesn't mention critical behaviors: whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting pull requests), or what happens on success/failure. The schema's 'force' parameter hints at unmerged branch handling, but the description doesn't explain this behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at three words with zero wasted language. It's front-loaded with the core action and resource. While under-specified, every word earns its place by stating the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 4 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't address behavioral risks, success conditions, error scenarios, or relationship to sibling tools. The agent lacks sufficient context to use this tool safely and effectively despite the good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all 4 parameters. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a branch' is a tautology that merely restates the tool name without adding meaningful context. While it clearly indicates a deletion action, it doesn't specify what type of branch (Git branch in Bitbucket) or distinguish this tool from potential alternatives among siblings like 'remove_requested_changes' or 'merge_pull_request' that might also involve removal operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 doesn't mention prerequisites (e.g., needing a branch to exist), exclusions (e.g., not for deleting protected branches), or sibling tools like 'get_branch' for verification. This leaves the agent with no context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Approve a pull request' implies a write/mutation operation that likely requires specific permissions and changes the PR state, but it doesn't disclose any behavioral traits such as required authentication, side effects (e.g., triggering merges), rate limits, or what happens on success/failure. The description is minimal and lacks critical context for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Approve a pull request', which is front-loaded and wastes no words. It directly states the tool's purpose without unnecessary elaboration, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (approving PRs) with no annotations and no output schema, the description is incomplete. It fails to cover behavioral aspects like permissions, side effects, or return values, and doesn't address usage context relative to siblings. For a tool that modifies data, this minimal description leaves significant gaps for an AI agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'Pull request ID', 'Repository slug'). The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or format specifics. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Approve a pull request' clearly states the action (approve) and resource (pull request), but it's vague about what 'approve' entails in this context (e.g., formal approval vs. informal). It distinguishes from siblings like 'unapprove_pull_request' by being the opposite action, but doesn't differentiate from other PR-related tools like 'merge_pull_request' or 'update_pull_request' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing review permissions), when not to use it (e.g., if changes are requested), or direct alternatives like 'request_changes' or 'merge_pull_request'. Usage is implied only by the tool name and context, with no explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('create') but doesn't explain what happens upon creation (e.g., whether it triggers notifications, requires permissions, or has side effects like branch management). It lacks details on error conditions, response format, or any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary words or redundant information are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a pull request (a mutation operation with 8 parameters, no annotations, and no output schema), the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or what the tool returns, leaving significant gaps for an AI agent to understand how to use it effectively beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional meaning or context about the parameters beyond what's in the schema, such as explaining relationships between parameters (e.g., source and destination branches) or usage tips. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new pull request' clearly states the action (create) and resource (pull request), but it's generic and doesn't differentiate from sibling tools like 'update_pull_request' or 'merge_pull_request'. It lacks specificity about what distinguishes this creation operation from other pull request operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'update_pull_request' or 'merge_pull_request'. The description doesn't mention prerequisites, such as needing existing branches or repository access, or when not to use it (e.g., for modifying existing pull requests).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose that merging is a destructive write operation, potential permission requirements, side effects (e.g., closing the PR), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to scan and understand quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a complex mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context: what merging does (e.g., integrates changes, closes PR), success/failure behaviors, or return values. For a tool with 6 parameters and significant impact, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining how parameters interact (e.g., merge_strategy affects commit_message). Baseline 3 is appropriate since the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('merge') and resource ('a pull request'), which is clear but basic. It doesn't differentiate from siblings like 'approve_pull_request' or 'update_pull_request', which are related but distinct operations. The purpose is understandable but lacks specificity about what merging entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., pull request must be approved or in a mergeable state), exclusions, or how it relates to siblings like 'update_pull_request' for modifying PRs. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool retrieves 'detailed information' and includes 'associated pull requests,' but fails to specify critical details such as authentication requirements, rate limits, error conditions, or the format of the returned data. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool with four parameters and no structured output information. It does not cover behavioral aspects like error handling or data format, leaving the AI agent with incomplete context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all four parameters. The description adds minimal value beyond the schema by implying that 'associated pull requests' relate to the 'include_merged_prs' parameter, but does not elaborate further. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a branch including associated pull requests.' It specifies the verb ('Get') and resource ('branch'), but does not explicitly differentiate it from sibling tools like 'list_branches' or 'get_pull_request', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not clarify when to choose 'get_branch' over 'list_branches' or 'get_pull_request', nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it mentions 'optional filtering', it doesn't describe important behavioral aspects: what format the diff is returned in (unified diff? patch format?), whether it's paginated for large diffs, authentication requirements, rate limits, or error conditions. For a tool that retrieves potentially complex data with 7 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get the diff/changes for a pull request') and adds qualifying information ('with optional filtering'). There's no wasted verbiage or redundant information. Every word earns its place in this concise formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (diff format, structure, size limitations) or important behavioral constraints. While the schema covers parameter documentation well, the description fails to provide the contextual information needed to understand how to effectively use this tool and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-documented in the schema itself. The description adds minimal value beyond the schema - it mentions 'optional filtering' which aligns with parameters like 'exclude_patterns', 'include_patterns', and 'file_path', but doesn't provide additional semantic context. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the diff/changes for a pull request with optional filtering'. It specifies the verb ('Get'), resource ('diff/changes for a pull request'), and scope ('optional filtering'). However, it doesn't explicitly distinguish this tool from potential siblings like 'get_pull_request' or 'list_pr_commits', which might also provide diff-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'get_pull_request' (which might include diff info) and 'list_pr_commits' (which might show commit-level changes), there's no indication of when this specific diff-focused tool is preferred. The mention of 'optional filtering' hints at use cases but doesn't provide explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'detailed information' but doesn't specify what details are included (e.g., commit hash, author, date, message) or behavioral traits like pagination, rate limits, or error handling. The description is vague and lacks critical operational context for a tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly listing key filtering options. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format, pagination behavior, or error cases, leaving significant gaps for the agent. Without annotations or output schema, the description should provide more context on what 'detailed information' entails and how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the input schema. The description adds minimal value beyond the schema by implying filtering options ('with detailed information and filtering options'), but doesn't provide additional semantics, examples, or clarification on parameter interactions. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'List commits in a branch with detailed information and filtering options,' which specifies the verb ('List'), resource ('commits in a branch'), and scope ('detailed information and filtering options'). It distinguishes from siblings like 'list_branches' (which lists branches) and 'list_pr_commits' (which lists commits for pull requests), but doesn't explicitly differentiate from 'list_directory_content' or 'search_code' in terms of commit-specific filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools like 'list_pr_commits' for pull request commits or 'search_code' for code search, nor does it specify prerequisites or contexts for usage. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 but offers minimal information. It doesn't mention that this is a read-only operation (implied by 'List'), pagination behavior (though hinted in schema), rate limits, authentication requirements, or what the output format looks like (no output schema). The description adds almost no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose ('List branches in a repository'), making it immediately clear. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't explain the return format, pagination strategy, error conditions, or how it differs from similar tools. The high schema coverage helps, but the description alone leaves significant gaps for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameters are well-documented in the structured data. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how 'filter' interacts with 'limit') or provide usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('branches in a repository'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_branch' (which retrieves a single branch) or 'list_branch_commits' (which lists commits for a branch), missing an opportunity for clearer distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention that 'get_branch' is for retrieving details of a specific branch, or that 'list_branch_commits' focuses on commit history rather than branch listing. There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions listing files and directories but fails to describe key behaviors like pagination, rate limits, authentication needs, error handling, or the format of the output (e.g., whether it returns metadata or just names). This leaves significant gaps for an agent to understand how to interact with the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and usage context, which are crucial for an agent to operate the tool correctly in a real-world scenario with sibling tools available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters with their purposes and optionality. The description adds no additional semantic context beyond what the schema provides, such as examples of path formats or branch behaviors, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the target ('files and directories in a repository path'), which is specific and understandable. However, it does not explicitly differentiate from sibling tools like 'search_code' or 'get_file_content', which might have overlapping purposes, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'search_code' or 'get_file_content', nor does it mention any prerequisites or exclusions. It only states what the tool does, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does but lacks critical details like whether it's read-only (implied by 'List' but not explicit), pagination behavior (though hinted by parameters), rate limits, authentication needs, or error handling. This is a significant gap for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward listing tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like safety, pagination details beyond parameters, or what the return format looks like (e.g., list of commit objects). For a tool in this context, more guidance is needed to help the agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 5 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters like how 'workspace', 'repository', and 'pull_request_id' combine). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('commits that are part of a pull request'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_branch_commits' or 'get_pull_request_diff', which also involve commits or pull requests, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention how it differs from 'list_branch_commits' (which lists commits for a branch) or 'get_pull_request' (which might include commit info), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'optional filters' but doesn't describe key behaviors: whether results are paginated (implied by 'start' parameter but not explained), default ordering, rate limits, authentication needs, or what the output looks like. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List pull requests for a repository') and adds qualifying information ('with optional filters'). There's no wasted language or redundancy—every word serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like pagination, ordering, or output format, nor does it provide usage context. While the schema covers parameters well, the overall tool understanding remains incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 6 parameters thoroughly with descriptions, defaults, and enums. The description adds minimal value beyond stating 'optional filters'—it doesn't explain parameter interactions, filtering logic, or provide usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List pull requests') and resource ('for a repository'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_pull_request' (singular) by indicating it returns multiple items, though it doesn't explicitly contrast with other list tools like 'list_branches' or 'list_pr_commits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives. It doesn't specify when to choose this over 'get_pull_request' for a single PR, or how it relates to 'list_pr_commits' or other list tools. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a mutation ('Remove') but does not specify permissions required, whether the action is reversible, or any side effects (e.g., notifications, status changes). This leaves significant gaps for a tool that modifies pull request states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., effects, error conditions) and does not compensate for the absence of structured data, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters documented in the input schema. The description does not add any additional meaning or context beyond what the schema provides (e.g., it does not explain how parameters interact or typical use cases), so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('change request from a pull request'), providing a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'unapprove_pull_request' or 'update_pull_request', which might have overlapping contexts in pull request management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not specify prerequisites (e.g., that a change request must exist) or contrast with tools like 'approve_pull_request' or 'unapprove_pull_request' in handling pull request states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states the action but doesn't explain what 'request changes' actually does (e.g., does it block merging? Is it reversible? What permissions are required?). For a mutation tool affecting pull request state, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is insufficient. It doesn't explain what happens after requesting changes, what the tool returns, error conditions, or behavioral implications. Given the complexity of pull request workflows and the presence of many sibling tools, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide extra value like explaining parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 target resource ('on a pull request'), making the purpose immediately understandable. It distinguishes from siblings like 'approve_pull_request' or 'merge_pull_request' by indicating a different review action. However, it doesn't specify what 'request changes' entails operationally beyond the basic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing review permissions), timing considerations, or how this differs from similar tools like 'add_comment' or 'update_pull_request'. Without this context, an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Remove approval' implies a mutation operation, it lacks details on permissions required, whether the action is reversible, rate limits, or what happens if no approval exists. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It is front-loaded with the core action and resource, making it highly efficient and easy to parse, which is ideal for quick understanding by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations or output schema, the description is incomplete. It fails to address critical aspects like error conditions, response format, or behavioral nuances (e.g., idempotency), leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (workspace, repository, pull_request_id). The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 the action (remove approval) and resource (pull request), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'remove_requested_changes' or 'update_pull_request', which might involve similar pull request modifications but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., needing an existing approval to remove), exclusions, or comparisons to siblings like 'approve_pull_request' or 'remove_requested_changes', leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions retrieving 'details' and 'merge commit information', but fails to specify whether this is a read-only operation, what authentication or permissions are required, or any rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every word contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters, no output schema, and no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are important for a tool interacting with a version control system like Bitbucket.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three required parameters. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'Bitbucket pull request details including merge commit information', which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_pull_request_diff' or 'list_pull_requests', which would require more precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'list_pull_requests' (for listing) or 'get_pull_request_diff' (for diff details). It lacks explicit when/when-not statements or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'enhanced context-aware search patterns' and Bitbucket Server limitation, but doesn't cover important aspects like whether this is a read-only operation, performance characteristics, rate limits, authentication requirements, or what the search results look like. For a search tool with 8 parameters and no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that communicates the core purpose and limitation. It's front-loaded with the main functionality and includes the Bitbucket Server constraint as important context. No wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, search functionality) and absence of both annotations and output schema, the description is somewhat incomplete. It covers the what and where but lacks details about behavioral characteristics, result format, and operational constraints that would help an agent use it effectively. The schema provides parameter details but the description should add more context for this non-trivial search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 8 parameters. The baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context about how parameters interact or best practices for search patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for code across Bitbucket repositories with enhanced context-aware patterns, specifying the verb 'search' and resource 'code across Bitbucket repositories'. It distinguishes from siblings by focusing on code search rather than pull requests, branches, or file operations, though it doesn't explicitly contrast with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for code search in Bitbucket repositories with context-aware patterns, and mentions 'currently only supported for Bitbucket Server' which provides some platform context. However, it doesn't explicitly state when to use this tool versus alternatives like get_file_content or list_directory_content for different search needs, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds value by mentioning 'smart truncation for large files,' which hints at performance or size-handling behavior beyond basic retrieval. However, it lacks details on error handling, rate limits, authentication needs, or what 'smart truncation' entails specifically, leaving gaps for a mutation-free read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get file content from a repository') and adds a key behavioral note ('with smart truncation for large files') without any wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema, no annotations), the description is somewhat complete by stating the purpose and a key behavior. However, it lacks details on return values, error cases, or how truncation interacts with parameters, which would enhance completeness for a read operation without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 7 parameters thoroughly. The description adds minimal semantic context by implying truncation relates to parameters like 'full_content' and 'line_count,' but doesn't provide additional meaning beyond what the schema specifies, aligning with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get file content') and resource ('from a repository'), specifying the core functionality. However, it doesn't explicitly differentiate from sibling tools like 'list_directory_content' or 'search_code' that might also access repository content, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving file content with truncation for large files, suggesting a context for handling size constraints. However, it provides no explicit guidance on when to use this tool versus alternatives like 'list_directory_content' or 'search_code', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'When updating without specifying reviewers, existing reviewers and their approval status will be preserved.' This clarifies a non-obvious side effect of the reviewers parameter, adding valuable context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and zero waste. The first sentence states the core purpose, and the second adds crucial behavioral context, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is adequate but has clear gaps. It explains the reviewers behavior well but doesn't cover other aspects like error conditions, permission requirements, or what the tool returns, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only reinforcing the reviewers behavior. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'existing pull request', making the purpose specific. It distinguishes from sibling tools like create_pull_request (creation) and merge_pull_request (merging), establishing its unique role in modifying existing PRs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 it ('update an existing pull request'), but lacks explicit guidance on when not to use it or alternatives for specific scenarios. It doesn't mention prerequisites like authentication or compare it to tools like get_pull_request for viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 does an excellent job explaining the tool's capabilities and constraints (e.g., 'you can either provide exact line_number or use code_snippet to auto-detect the line', 'For inline comments, you can either provide exact line_number or use code_snippet'). It clarifies the tool's behavior beyond basic parameter documentation, though it doesn't mention permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: it starts with the core purpose, then lists the four supported use cases in a clear numbered format, and adds specific guidance for inline comments. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 13 parameters, no annotations, and no output schema, the description does an excellent job explaining the tool's functionality and parameter relationships. It covers the main use cases comprehensively. The only minor gap is the lack of information about return values or error conditions, which would be helpful given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the relationships between parameters (e.g., 'Use this instead of line_number for auto-detection', 'Use this OR code_snippet, not both', 'Required for inline comments'), which helps the agent understand how to combine parameters correctly for different use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('comment to a pull request'), and distinguishes this tool from siblings by specifying four specific use cases (general PR comments, replies, inline comments, code suggestions). It goes beyond the tool name to explain the scope of functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by listing the four supported comment types, which helps the agent understand appropriate use cases. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools (e.g., when to use update_pull_request instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bitbucket-mcp-server MCP server](https://glama.ai/mcp/servers/pdogra1299/bitbucket-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/pdogra1299/bitbucket-mcp-server)

Score Badge

Copy to your README.md:

[![bitbucket-mcp-server MCP server](https://glama.ai/mcp/servers/pdogra1299/bitbucket-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/pdogra1299/bitbucket-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pdogra1299/bitbucket-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server