Bitbucket MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct resource and action: pull request lifecycle (create, update, get, list, merge, approve, unapprove, request/remove changes, comment, diff, commits), branch management (get, list, delete, commits), and file browsing (list directory, get file). No two tools have overlapping purposes, and descriptions clearly differentiate similar-sounding operations like list_branch_commits vs list_pr_commits.
Naming Consistency4/5
Tool names generally follow a clear verb_noun pattern (e.g., create_pull_request, list_branches, get_file_content). Minor inconsistencies exist: 'list_pr_commits' abbreviates 'pull_request' while other tools use the full term, and 'add_comment' lacks the 'pull_request' qualifier. Overall, the naming is predictable and readable with only small deviations.
Tool Count4/5
With 19 tools, the server is slightly above the ideal 3-15 range but remains well-scoped for a Bitbucket MCP covering repositories, branches, pull requests, and code search. Each tool serves a distinct purpose, and the count is justified by the breadth of PR workflow actions (approve, request changes, comment, merge, diff, etc.). It feels comprehensive rather than bloated.
Completeness3/5
The tool surface covers most of the core Bitbucket workflows, especially pull requests (create, update, list, get, merge, approve, request changes, comment, diff, commits). However, notable gaps exist: there is no create_branch (only get, list, delete), no decline_pull_request, and no way to edit or commit file content. These missing operations could hinder agents in common scenarios, though many workarounds are possible.
Average 3.3/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely restates the action without mentioning side effects (e.g., creating a PR in Bitbucket), required permissions, potential failures, or the outcome of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is appropriately front-loaded and concise, though minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is too minimal to provide complete context. It does not explain the expected result, error scenarios, or how this tool fits into the pull request lifecycle beyond the obvious act of creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 8 parameters thoroughly. The description adds no additional parameter semantics, but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new pull request' uses a specific verb and resource, clearly distinguishing the action from sibling tools like update_pull_request or merge_pull_request. However, it lacks any additional detail about scope or context, such as the Bitbucket workspace or repository, which are only found in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The verb 'create' implies a new resource, but the description does not state exclusions (e.g., do not use this to update existing PRs) or mention any prerequisites like branch existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Approve a pull request' without mentioning state changes, permissions, reversibility, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, achieving excellent conciseness. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 lacks necessary context. It does not explain what happens upon approval, whether the operation is reversible, or what response to expect, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly described. The tool description adds no additional parameter information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'approve' and resource 'pull request', clearly distinguishing it from siblings like 'request_changes' or 'merge_pull_request'. However, it is very terse and could be more explicit about what approving entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as 'request_changes' or 'unapprove_pull_request'. It simply states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails to mention that this is a destructive, irreversible operation, the existence of a force flag, or any error conditions. The description adds no behavioral insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. It is appropriately concise, though under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks any mention of safety implications, force behavior, or failure conditions, leaving the agent without sufficient context to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the baseline is 3. The description itself does not add any parameter-related meaning, but the schema fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a branch" clearly states the action and resource, distinguishing it from siblings like get_branch or list_branches. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, any prerequisites (e.g., branch must be merged), or alternatives. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read operation via 'List', but does not mention default state filtering (OPEN), pagination behavior, or return format. This is minimal and does not expose important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the verb and resource. Every word contributes to the core purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain default behavior, pagination semantics, or what the returned list contains, leaving significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are fully described in the input schema, so the description adds no parameter-level detail beyond the generic note about 'optional filters'. With schema coverage at 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'pull requests', scoped to 'a repository', clearly indicating a multi-item listing operation. It indirectly distinguishes from 'get_pull_request' via the plural form, but does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like get_pull_request, create_pull_request, or merge_pull_request. It only states the basic function with no exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It simply says 'Merge a pull request', but does not state that merging is an irreversible action, what side effects occur (e.g., source branch closing), or whether special permissions are required. The schema hints at some parameters, but the description itself adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and not verbose. It is crisp but lacks substantive content; still, for conciseness alone, it is appropriately sized—though under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with six parameters, no annotations, and no output schema. It fails to explain merge strategies, optional fields, side effects (like source branch deletion), or what happens after the merge. The rich schema cannot compensate for the lack of high-level behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented with descriptions and enum values. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'merge' with a clear resource ('a pull request'), which distinguishes it from sibling tools like create, update, approve, or request changes. However, it lacks any additional context (e.g., platform, scope) beyond the inherent meaning of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 approve_pull_request or update_pull_request. The description does not mention prerequisites, when merging is appropriate, or any caveats about merge strategies or branch deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral trait of smart truncation for large files, which adds value beyond the raw schema. However, with no annotations provided, the description carries the full burden and only vaguely references 'smart truncation' without explaining specifics like response formats, binary file handling, or permission requirements. This is partial disclosure, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose and key behavioral aspect. It is front-loaded and contains no filler. Every word contributes value, making it exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the one-sentence description is insufficient for full contextual understanding. It does not explain the truncation mechanism, potential return values, error handling, or how to retrieve full content (despite full_content being a parameter). The tool's behavior remains underspecified, so completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description mentions truncation, which relates to parameters like line_count and full_content, but adds no specific parameter-level meaning beyond what the schema already provides. Thus, it meets the baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches file content from a repository, using the verb 'Get' and specific resource 'file content'. It includes a distinctive feature ('smart truncation for large files') that adds context. While it does not explicitly distinguish from siblings like list_directory_content, the action is unique enough; a 4 is appropriate for clear verb+resource but no explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any exclusions or conditions. It simply states what the tool does without contextual advice. Since there is no mention of when not to use it or how it compares to other tools, the score is 2 ('no guidance').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure but falls short. It does not mention that results are paginated (the schema includes limit and start parameters), nor does it clarify that 'all commits' may be limited by default (max 25). It also fails to specify output format, ordering, or how commits are defined relative to the PR. The word 'all' could mislead users into expecting every commit regardless of pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It avoids unnecessary words or repetition, making it extremely efficient while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (pagination, PR association, no output schema), the description provides minimal context. It does not clarify what 'part of a pull request' means (e.g., commits on the source branch), how pagination is handled, or what fields are returned. The schema covers parameters, but the description lacks behavioral and return-value details, making it insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters, giving 100% coverage. The description adds no semantic value beyond the schema; it does not explain how parameters interact (e.g., that limit and start control pagination). Since schema coverage is high, a baseline score of 3 is appropriate, but the description could have reinforced key parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly and specifically states the tool's function: 'List all commits that are part of a pull request'. It uses a specific verb (list) and a distinct resource (commits within a pull request), which distinguishes it from sibling tools like list_branch_commits or get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when not to use it, such as when needing branch commits instead (list_branch_commits), nor does it reference any sibling tools or usage context. The only implication is that it is used for PR commits, but no explicit differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose side effects (e.g., changing the pull request review status), permissions required, or behavior if no change request exists. This is a mutation tool with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is easily parsed and efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description omits critical context about what 'change request' means in the Bitbucket review workflow, the effect on the PR status, and any preconditions. With no annotations, the tool is under-specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (workspace, repository, pull_request_id) with 100% coverage. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 the target ('change request from a pull request'), making it distinct from the sibling tool request_changes which adds a change request. The verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, whether a prior change request must exist, or how it fits with approve/unapprove flows. There are no exclusions or alternatives mentioned, leaving the agent to infer usage from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'detailed information and filtering options' without explaining any behavioral specifics like pagination, ordering, default values for include_merge_commits, or return format. It does not even explicitly state that the operation is read-only beyond the verb 'List'. The description adds little value over the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the primary action. It is appropriately sized for the tool's complexity, though it could be slightly more structured by explicitly listing key filtering capabilities. It earns a 4 for being efficient and avoid unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description is far too brief to provide adequate context. It does not explain return value structure, pagination behavior, default limits (though defaults are in schema), or any special considerations like how merge commits are handled. The description leaves significant gaps for an agent to understand the full behavior and output of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 10 parameters have descriptions), so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides. It mentions 'filtering options' generically, which is already covered by the parameter descriptions for since, until, author, search, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function: listing commits in a branch. It uses a specific verb ('List') and resource ('commits in a branch'), which distinguishes it from siblings like list_pr_commits (in a pull request) and list_branches (listing branches). However, the phrase 'detailed information and filtering options' is somewhat vague and does not explicitly distinguish from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need commits from a specific branch, providing clear context. It does not mention alternatives or exclusions, but the resource and scope are explicit enough that an AI agent can infer when to invoke it. This meets the 'clear context, no exclusions' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the action without explaining consequences (e.g., whether this blocks merging, creates a review thread, or notifies the author). The mutation effect is implied but not elaborated, which is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It contains no filler, redundancy, or unnecessary detail, making it easy to parse and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 and full schema coverage, the description is minimally adequate but lacks behavioral context (e.g., effect on PR state) that would be expected for a mutation tool with no annotations. It answers 'what' but not 'so what' or 'what next', leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all four parameters (workspace, repository, pull_request_id, comment). The description adds no parameter-level details beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 the resource ('a pull request'), using a specific verb and object. It distinguishes itself from sibling tools like approve_pull_request, unapprove_pull_request, and merge_pull_request by naming a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 add_comment or update_pull_request. There is no mention of preconditions, typical scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only mentions 'optional filtering' but does not explain output format, pagination, how filters interact, or any limitations. This is insufficient for a tool with no supporting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core function and optional filtering without waste. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, a one-sentence description is inadequate. It does not explain what the diff includes, how filters combine, or any edge cases, making the tool harder to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The phrase 'optional filtering' adds general context for the include/exclude and file_path parameters but does not provide syntax or behavioral details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the diff/changes for a pull request with optional filtering.' This uses a specific verb and resource, and distinguishes it from sibling tools like get_pull_request (which likely returns metadata) and get_file_content (which fetches file contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 pull request changes but does not explicitly state when to use this tool versus alternatives. No mention of exclusions or specific circumstances, though the purpose itself suggests the main use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'list branches' and does not mention pagination behavior, response format, permissions, or any side effects. This is a significant gap for a tool with pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is appropriately sized for a simple list operation, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic list tool, the description is sufficient for an agent to understand what it does. The schema covers all parameters, and while the description does not mention return values, the absence of an output schema makes that less critical. However, the lack of behavioral transparency slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, providing detailed meaning for all five parameters. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List branches in a repository' clearly states the action (list) and the resource (branches), with a scoping location (repository). It is specific enough to distinguish from sibling tools like delete_branch or get_branch, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to list branches in a repository—but it does not explicitly mention alternatives or exclusions. Usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states that it "gets" information, which implies a read-only operation, but it does not explicitly mention that it has no side effects, nor does it describe what "detailed information" includes or any default behaviors (e.g., whether merged PRs are included by default). The only behavioral hint is the mention of associated PRs, but this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose and includes a relevant detail about PRs. There is no redundant or filler text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description gives a general idea of the response (detailed branch info + associated PRs) but lacks specifics about return shape or edge cases. The explicit mention of "associated pull requests" adds value, yet the vague phrase "detailed information" leaves some uncertainty. Overall, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The description itself does not add parameter-specific meaning, but the schema already fully documents each parameter. Baseline 3 is appropriate since the description does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: "Get detailed information about a branch" and adds a distinguishing detail, "including associated pull requests." This differentiates it from sibling tools like list_branches (which lists branches) and get_pull_request (which gets a single PR). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user needs branch details along with associated PRs, but it does not explicitly state when to use this over alternatives or mention any exclusions. There is no direct guidance like "use list_branches for branch names only," so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the basic read operation ('List') but does not reveal important traits like whether the listing is recursive, includes hidden files, or how permissions are handled. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 and the schema's full parameter coverage, the description is minimally adequate. However, it lacks details about the return format or any recursive behavior, which would be useful since there is no output schema. It is incomplete in those respects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no extra meaning about parameters beyond what the schema already states, hence it neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('files and directories') within a repository path. It is unambiguous and distinguishes itself from siblings like get_file_content and list_branches by specifying directory listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: it is used to browse repository contents. However, there are no explicit instructions on when to choose this tool over alternatives, such as get_file_content for file retrieval or search_code for queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only hints at 'enhanced context-aware search patterns' without explaining what that means, nor does it disclose read-only nature, result format, pagination behavior, or any side effects. For a search operation, the agent is left guessing about the return payload and exact behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It leads with the primary action and resource, then adds a critical constraint (Bitbucket Server only). Every word is useful and no information is wasted, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description is minimal and does not explain key aspects such as the structure of results, default behavior (e.g., all repositories), or the meaning of 'context-aware' search. It lacks critical context that an agent needs to confidently invoke the tool, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's phrase 'context-aware search patterns' loosely maps to the 'search_context' parameter, but it does not add meaningful parameter-specific information beyond what the schema already provides. It does not clarify usage of parameters like 'file_pattern' or 'include_patterns' further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for code across Bitbucket repositories.' It uses a specific verb ('search'), names the resource ('code' in Bitbucket repositories), and is distinct from sibling tools (which focus on pull requests, branches, and file content). The mention of 'enhanced context-aware search patterns' further specifies its unique capability, though not fully detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the tool (searching code) and includes an explicit constraint: 'currently only supported for Bitbucket Server.' This helps agents avoid using it for Bitbucket Cloud. However, it does not mention alternatives because no sibling tools offer code search, so the 'when-not' is partially covered by the server restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It only states 'Remove approval from a pull request' without disclosing side effects, permissions, behavior when no approval exists, or irreversibility. This is a mutation tool with minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the action and object. It is concise with no repetitive or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation, three required parameters with full schema descriptions, and no output schema, the description is largely complete. It states what the tool does and the schema covers arguments. However, behavioral details (e.g., effect if no approval exists) are absent, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (workspace, repository, pull_request_id) at 100% coverage. The description adds no additional parameter semantics, but none are needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 a specific action (remove approval) and the resource (pull request). It distinguishes itself from siblings like approve_pull_request and remove_requested_changes, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as approve_pull_request or remove_requested_changes. The intended usage is implied by the name and verb, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates this is a read operation ('Get details') and mentions the inclusion of merge commit information, which is useful context. However, it does not disclose potential errors, authentication requirements, or the exact shape of the response beyond merge commit info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and a key detail. Every word earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three well-documented parameters and no output schema, the description is reasonably complete. It tells the agent what to expect (details including merge commit info). However, it could be more specific about what 'details' encompasses or that it returns the full pull request object, which would provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, covering 100% of the schema. The description itself adds no extra parameter-level meaning, but this is acceptable because the schema already fully documents workspace, repository, and pull_request_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get'), a specific resource ('details of a Bitbucket pull request'), and an explicit detail ('including merge commit information'). It distinguishes this tool from siblings like list_pull_requests (which lists) and update_pull_request (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need details of a single pull request) but does not explicitly state when not to use it or name alternatives. Given sibling tool names, usage context is somewhat implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a genuinely important behavioral trait—preserving reviewers and approval status when reviewers are not specified—which is valuable beyond the basic update action. However, with no annotations, it does not address permissions, reversibility, or other side effects, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loaded with the primary action and immediately followed by a critical caveat. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description covers the key reviewer preservation nuance but omits other update semantics (e.g., partial vs full update, response shape, prerequisites). The schema fills parameter details, but the tool description is lean for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All seven parameters are already fully described in the input schema (100% coverage), and the tool description essentially repeats the reviewer caveat already present in the schema. It adds no new semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Update an existing pull request') and adds a clarifying behavioral note about reviewer preservation, which helps distinguish it from create_pull_request or merge_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing pull request' clearly signals it is for modifying already-created PRs, and the reviewer caveat gives a concrete usage condition. It does not explicitly mention alternatives like create_pull_request, but the context and sibling tool names make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds meaningful context by explaining supported comment types, the auto-detection behavior of code_snippet, and the distinction between single and multi-line suggestions. This goes beyond a simple 'add comment' statement, though it does not mention side effects or error handling (e.g., strict match failures), which are partially covered in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses a numbered list to structure four distinct capabilities. Every sentence adds value without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 params, nested objects, no output schema), the description covers the main functionality and usage patterns well. It lacks explicit guidance on some edge cases or return values, but the schema compensates. The description is complete enough for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for all 13 parameters, including relationships like 'Use this OR code_snippet, not both.' The description adds a high-level synthesis of modes but does not provide additional parameter-level semantics beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Add a comment to a pull request') and enumerates four distinct modes: general comments, replies, inline comments, and code suggestions. This differentiates it from sibling tools like approve_pull_request or request_changes, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for adding comments) and provides guidance on selecting modes (e.g., line_number vs code_snippet). It does not explicitly contrast with alternatives, but the four-mode breakdown gives clear context for choosing among tool features. No exclusions are stated, but the tool's scope is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Score Badge

Copy to your README.md:

[![bitbucket-mcp-server MCP server](https://glama.ai/mcp/servers/zhanglc/bitbucket-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/zhanglc/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/zhanglc/bitbucket-mcp-server'

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