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
Every tool has a clearly distinct purpose targeting specific resources and actions in the Bitbucket domain. There is no overlap or ambiguity between tools like 'get_branch', 'list_branches', 'compare_branches', or 'get_pull_request', 'list_pull_requests', 'merge_pull_request'.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern throughout (e.g., 'list_repositories', 'get_commit', 'create_pull_request'). The naming is uniform with clear action prefixes and descriptive resource names, making the set predictable and readable.
Tool Count4/5
With 16 tools, the count is slightly on the higher side but reasonable for a comprehensive Bitbucket server covering repositories, branches, commits, pull requests, and workspaces. It's well-scoped, though it might feel heavy compared to simpler servers.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for the Bitbucket domain, including listing, getting, creating, merging, and commenting on pull requests, along with repository, branch, commit, and workspace operations. There are no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 2.8/5 across 16 of 16 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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

Behavior1/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. The description only states the action ('create') without any information about permissions required, side effects, error conditions, rate limits, or what happens upon success. For a mutation tool with zero annotation coverage, this is a critical 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 extremely concise at just four words, with no wasted language. It is front-loaded with the core action, though this brevity comes at the cost of completeness. Every word earns its place by directly stating the tool's purpose, even if minimally.
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), the lack of annotations, and no output schema, the description is incomplete. It fails to address critical aspects like required permissions, what the tool returns, or how it interacts with the system, leaving significant gaps for an AI agent to operate 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 description adds no parameter semantics beyond what the input schema provides. However, with 100% schema description coverage, the baseline score is 3, as the schema already documents all parameters adequately. The description does not compensate or add value, but it also doesn't detract from the schema's completeness.
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 'Create a new pull request' is a tautology that essentially restates the tool name without adding meaningful context. It specifies the verb 'create' and resource 'pull request' but lacks specificity about what a pull request entails in this system or how it differs from sibling tools like 'merge_pull_request' or 'list_pull_requests'.
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. There are no mentions of prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage from the tool name alone. This is particularly problematic given sibling tools like 'merge_pull_request' and 'list_pull_requests' that handle related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails to describe any behavioral traits such as permissions required, rate limits, pagination, or what the search returns (e.g., list of files, code snippets). The phrase 'Search for code' is too generic and doesn't add meaningful context 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.
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 and appropriately sized for a basic tool, avoiding unnecessary elaboration. Every word contributes to stating the purpose, though it lacks depth.
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 search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., search results format), behavioral aspects like performance or limitations, or how it integrates with sibling tools. For a tool with 2 parameters and no structured output, more context is needed to be fully helpful.
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 both parameters ('workspace' and 'query') documented in the schema. The description adds no additional meaning beyond the schema, such as examples of query syntax or workspace constraints. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.
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 'Search for code in a workspace' states the basic action (search) and target (code), but it's vague about scope and lacks sibling differentiation. It doesn't specify what 'code' means (e.g., files, snippets, repositories) or how the search works (e.g., text matching, regex). Compared to siblings like 'get_file_content' or 'list_repositories', the distinction is implied but not explicit.
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 doesn't clarify if this is for finding code snippets across repositories versus within a single file, or when to prefer 'get_file_content' for direct access. The description offers only a basic function without context or exclusions.
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. 'Approve' implies a write/mutation operation that changes pull request state, but the description doesn't specify what happens after approval (does it trigger merges? change status?), what permissions are required, whether the action is reversible, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant behavioral information 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 maximally concise - a single four-word phrase that communicates the core function without any wasted words. It's front-loaded with the essential action and resource. For such a simple tool, this level of conciseness is appropriate and efficient.
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 mutation tool (approving pull requests) with no annotations and no output schema, the description is incomplete. It doesn't explain what 'approve' means operationally, what happens after approval, what permissions are needed, or what the tool returns. For a tool that presumably changes system state, more behavioral context is needed despite the concise description.
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 fully documents all three parameters (workspace, repo_slug, pr_id). The description adds no parameter information beyond what's in the schema - it doesn't explain parameter relationships, format expectations, or provide examples. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
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 ('Approve') and resource ('a pull request'), which provides basic purpose. However, it doesn't distinguish this tool from sibling tools like 'merge_pull_request' or 'add_pull_request_comment' - it's unclear how approval differs from merging or what specific approval action is performed. The description is functional but lacks specificity about what 'approve' means in this context.
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. There's no mention of prerequisites (e.g., needing review permissions), when approval is appropriate versus merging, or how it relates to sibling tools like 'merge_pull_request' or 'add_pull_request_comment'. The agent must infer usage context entirely from the tool name and sibling names.
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 the action ('compare') but doesn't describe what the comparison entails (e.g., output format, whether it's read-only, potential side effects, or error conditions). This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 'Compare two branches', a single phrase that front-loads the core purpose without unnecessary words. Every part earns its place, making it efficient and easy to parse, though it may be overly brief for 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 complexity of a comparison tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the comparison returns (e.g., diff, commit list), behavioral traits, or how it fits with sibling tools. This leaves the agent with insufficient context to use the tool effectively beyond basic 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 parameter descriptions in the input schema (e.g., 'workspace slug', 'repository slug'). The tool description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
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 'Compare two branches' clearly states the verb (compare) and resource (branches), making the purpose understandable. However, it lacks specificity about what aspects are compared (e.g., commits, files, diffs) and doesn't distinguish it from sibling tools like 'get_branch' or 'list_commits', which might provide related information. This makes it vague but not misleading.
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 a workspace or repository context), exclusions, or how it relates to sibling tools like 'get_commit' or 'list_commits' for similar comparisons. Usage is implied only by the tool name, 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?
No annotations are provided, so the description carries full burden. 'Merge a pull request' implies a destructive write operation, but it lacks critical behavioral details: whether it requires specific permissions, what happens on success/failure (e.g., branch deletion), rate limits, or if it's idempotent. 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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool name and front-loaded with the core action, though this conciseness comes at the cost of detail.
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 merge operation (a destructive write with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to explain behavioral traits, error conditions, or return values, leaving significant gaps for an AI agent to use it correctly.
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 all three parameters (workspace, repo_slug, pr_id) documented in the schema. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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 'Merge a pull request' clearly states the action (merge) and resource (pull request), but it's vague about scope and mechanism. It doesn't specify whether this performs a fast-forward, squash, or merge commit, nor does it distinguish from sibling tools like 'approve_pull_request' or 'create_pull_request' 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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., pull request must be approved or mergeable), exclusions (e.g., cannot merge if conflicts exist), or related tools like 'approve_pull_request' that might be needed first.
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 ('Add a comment') but doesn't mention whether this requires authentication, what permissions are needed, if there are rate limits, how errors are handled, or what the response looks like (e.g., success confirmation or comment ID). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 directly states the tool's purpose without fluff or repetition. It's appropriately sized and front-loaded, 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 this is a mutation tool (adding a comment) with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or response format, which are critical for an agent to invoke it correctly. The 100% schema coverage helps with parameters, but overall context is lacking.
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 documented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter relationships, format examples (e.g., what a 'workspace slug' looks like), or constraints. This meets the baseline of 3 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 action ('Add a comment') and target resource ('to a pull request'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from potential alternatives or siblings like 'approve_pull_request' or 'merge_pull_request', which also interact with pull requests but perform different 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing pull request), exclusions (e.g., not for issues or commits), or comparison with sibling tools like 'create_pull_request' or 'merge_pull_request'. The 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get details'), implying non-destructive behavior, but lacks details on authentication needs, rate limits, error conditions, or return format. This is insufficient for a tool with no 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, efficient sentence with zero wasted words. It's front-loaded with the core purpose, making it easy to scan and understand 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 no annotations and no output schema, the description is incomplete. It doesn't explain what details are returned, error handling, or how it differs from related tools. For a read operation with three required parameters, more context is needed to guide 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 three parameters. The description adds no additional meaning beyond implying the tool retrieves details for a branch, which aligns with the schema but doesn't provide extra context like parameter relationships or examples.
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 details') and resource ('a specific branch'), making the purpose understandable. It doesn't distinguish from sibling tools like 'list_branches' or 'compare_branches', which would require explicit differentiation for a score of 5.
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_branches' or 'get_commit', nor does it mention prerequisites or context for usage. It simply restates the basic function without operational context.
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 full burden for behavioral disclosure. It states 'Get details' but doesn't clarify what details are returned (e.g., JSON structure, error handling), whether it's read-only (implied but not explicit), or any rate limits/permissions required. This leaves significant gaps for an agent to understand the tool's behavior.
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's front-loaded with the core action ('Get details') and efficiently specifies the target ('of a specific commit'). No unnecessary elaboration or redundancy is present.
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 no annotations and no output schema, the description is incomplete for a tool with three required parameters. It doesn't explain what 'details' entail (e.g., commit message, changes, timestamps), error scenarios, or return format, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 all three parameters clearly documented in the schema (workspace slug, repository slug, commit hash). The description adds no additional meaning beyond implying these are needed to identify a commit, so it meets the baseline for high schema coverage without compensating further.
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 ('details of a specific commit'), making the purpose understandable. It distinguishes from siblings like 'list_commits' by specifying retrieval of a single commit rather than listing multiple. However, it lacks specificity about what details are included (e.g., metadata, diff, author info).
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., needing a valid commit hash), contrast with 'list_commits' for browsing commits, or specify use cases like reviewing changes or checking commit status. The description alone offers no usage context.
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 the action but lacks details on permissions, rate limits, error handling, or output format. This is insufficient for a tool that likely involves network calls and file access, leaving key behavioral traits undefined.
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 highly concise and well-structured for quick comprehension.
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 file retrieval from a repository, with no annotations and no output schema, the description is incomplete. It does not cover behavioral aspects like authentication needs, error cases, or return value format, leaving significant gaps for the agent to operate 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 fully documents all parameters. The description adds no additional meaning beyond implying a file content retrieval context, which aligns with the schema but does not enhance parameter understanding. Baseline 3 is appropriate as the schema handles 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 'Get' and the resource 'content of a file from a repository', making the purpose specific and understandable. However, it does not explicitly differentiate from siblings like 'get_commit' or 'search_code', which might also retrieve file-related data, so it misses full 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 does not mention if this is for raw file content retrieval versus metadata or search operations, leaving the agent to infer usage from context without explicit direction.
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 the tool retrieves details but doesn't describe what 'details' include, whether it's a read-only operation, error conditions (e.g., invalid IDs), authentication needs, or rate limits. This leaves significant gaps for a tool that likely interacts with a version control system.
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, direct sentence that efficiently conveys the core action. It's front-loaded with the main purpose and avoids unnecessary words, though it could be slightly more informative without losing conciseness.
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 incomplete. It doesn't explain what details are returned (e.g., title, status, diff), error handling, or system-specific behaviors. For a tool with three parameters and likely complex data retrieval, this minimal description leaves too much undefined for effective agent 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?
The input schema has 100% description coverage, clearly documenting all three required parameters (workspace, repo_slug, pr_id). The description adds no parameter-specific information beyond implying a pull request ID is needed, so it meets the baseline of 3 where 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 tool's purpose as retrieving details of a specific pull request, using the verb 'Get' and specifying the resource 'pull request'. It distinguishes from siblings like list_pull_requests (which lists multiple) but doesn't explicitly differentiate from get_repository or get_commit, which retrieve different resource types.
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 a specific pull request ID), contrast with list_pull_requests for browsing, or indicate when other tools like get_commit might be more appropriate for related data.
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 it 'Get details' but doesn't clarify if this is a read-only operation, what permissions are required, how errors are handled, or the format of returned details. This leaves significant gaps 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.
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 any wasted words. It is appropriately sized and front-loaded, making it easy to understand 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 repository details tool with no annotations and no output schema, the description is incomplete. It lacks information on what details are returned, error conditions, or behavioral traits, making it insufficient for an agent to fully understand how to use this tool 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 schema description coverage is 100%, so the input schema already documents both parameters ('workspace' and 'repo_slug') adequately. The description adds no additional meaning beyond what the schema provides, such as examples or context for the parameters, meeting 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 verb ('Get') and resource ('details of a specific repository'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'list_repositories' or 'get_branch', which would require more specificity about what 'details' includes to reach a score of 5.
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, such as needing a specific repository, or compare it to siblings like 'list_repositories' for broader queries or 'get_branch' for branch-specific details, leaving usage context unclear.
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 basic function but lacks critical details: whether this is a read-only operation, if it requires authentication, what the return format looks like (e.g., list of branch names with metadata), or if there are pagination or rate limits. This leaves significant gaps for an 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 with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple list operation, 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of branch objects with names, commits, etc.), which is crucial for a list operation. For a tool with 2 parameters and no structured output, more context is needed to be fully helpful.
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 both parameters ('workspace' and 'repo_slug') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as explaining how these slugs are formatted or where to find them, but this is acceptable given the 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 all branches') and the resource ('in a repository'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_branch' or 'compare_branches', which prevents 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. It doesn't mention when to choose 'list_branches' over 'get_branch' (for a single branch) or 'compare_branches' (for branch differences), nor does it specify any prerequisites or exclusions.
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 the action ('List commits') but fails to describe traits like pagination, rate limits, authentication needs, error conditions, or what the output looks like (e.g., list format, fields). This is a significant gap for a tool with no 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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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 (a list operation with filtering), lack of annotations, and no output schema, the description is incomplete. It does not address behavioral aspects like output format, pagination, or error handling, which are crucial for an agent to use the tool effectively. The description should provide more context to compensate for missing structured data.
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 parameters (workspace, repo_slug, branch). The description does not add any meaning beyond what the schema provides, such as explaining how 'branch' filtering works or providing examples. 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 'List commits in a repository' clearly states the verb ('List') and resource ('commits in a repository'), making the purpose immediately understandable. It does not distinguish from siblings like 'get_commit' (singular) or 'compare_branches', but it's specific enough to avoid vagueness or tautology.
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 lacks any mention of prerequisites, context (e.g., after creating a pull request), or exclusions, leaving the agent to 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it lists pull requests but doesn't mention critical behaviors like pagination, rate limits, sorting order, or what data is returned (e.g., full details vs. summaries). 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, direct sentence with zero wasted words. It front-loads the core purpose ('List pull requests') efficiently, making it easy to parse and understand at a glance 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 complexity of listing pull requests (which involves filtering, pagination, and data formatting), the description is incomplete. With no annotations and no output schema, it fails to address key contextual aspects like return format, error handling, or limitations (e.g., max results). This makes it inadequate for an agent to use the tool confidently without additional assumptions.
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 parameters (workspace, repo_slug, state) including an enum for state. The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage examples, which is acceptable given the 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 ('pull requests in a repository'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_pull_request' (singular) or 'search_code', which could also retrieve PR information in different contexts.
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 clarify when to choose 'list_pull_requests' over 'get_pull_request' (for a single PR) or 'search_code' (for broader searches), nor does it mention prerequisites like authentication or repository access.
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 offers minimal behavioral insight. It implies a read-only operation ('List') but doesn't disclose critical traits like pagination, rate limits, sorting, error conditions, or authentication requirements. For a tool with zero annotation coverage, this is inadequate, though not contradictory.
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 wasted words. It front-loads the core action ('List all repositories') and specifies the scope ('in a workspace') directly. Every element earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on behavioral aspects (e.g., pagination, errors), output format, or usage context. For a list operation that likely returns multiple items, 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%, with the parameter 'workspace' documented as optional with a default. The description adds no parameter-specific details beyond implying the workspace context. Since the schema handles the heavy lifting, the baseline 3 is appropriate—no extra value but no gap.
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 ('repositories'), specifying the scope ('in a workspace'). It distinguishes from siblings like 'get_repository' (singular) and 'list_branches'/'list_commits' (different resources). However, it doesn't explicitly differentiate from 'list_workspaces' or other list tools, keeping it at 4 rather than 5.
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., authentication), compare with 'get_repository' for single repos, or specify use cases like browsing vs. searching (contrast with 'search_code'). This lack of context leaves the agent without clear selection criteria.
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 the action ('List all available') but doesn't cover critical aspects like pagination, rate limits, authentication needs, or what 'available' means (e.g., accessible to the user). This leaves significant gaps for a tool that likely interacts with an API.
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 front-loads the key information ('List all available Bitbucket workspaces'), making it highly efficient and easy to parse.
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 simplicity (zero parameters, no output schema), the description is minimally adequate but lacks depth. Without annotations or output schema, it should ideally mention what the list returns (e.g., workspace names, IDs) or behavioral constraints, but it doesn't, leaving the agent with incomplete context for a read operation.
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?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets expectations by not adding unnecessary details. A baseline of 4 is appropriate for a zero-parameter tool.
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 with a specific verb ('List') and resource ('Bitbucket workspaces'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'list_repositories' or 'list_branches' beyond specifying the resource type, which prevents 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. It doesn't mention prerequisites, context, or comparisons to sibling tools like 'list_repositories' (which might list repositories within a workspace), leaving the agent to 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.

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 MCP server](https://glama.ai/mcp/servers/jlromano/bitbucket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jlromano/bitbucket-mcp)

Score Badge

Copy to your README.md:

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

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/jlromano/bitbucket-mcp'

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