Skip to main content
Glama
pdogra1299

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_pull_request

Edit a pull request's title, description, destination branch, reviewers, or attachments. Approvals stay unless reviewers change; pass version to prevent overwrites.

Instructions

Update a pull request. Reviewers/approvals are preserved unless reviewers is passed. Pass version (from get/list) to save a fetch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
versionNoEntity version from a prior read; supplying it saves a fetch AND makes the write conditional — it fails on concurrent modification instead of overwriting. Omit to write against the latest state (auto-retried once).
reviewersNoReplaces reviewer list; approvals preserved
workspaceYesProject key (e.g., PROJ)
repositoryYesRepository slug
attachmentsNoLocal files to upload & embed (Server/DC only). Item: path string or {file_path, alt_text?, render?: image|link|auto}
descriptionNo
pull_request_idYesPull request ID
destination_branchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv3.0.1
    • addedInput schema / properties / attachments
      Added value: +{
+  "description": "Local files to upload & embed (Server/DC only). Item: path string or {file_path, alt_text?, render?: image|link|auto}",
+  "items": {
+    "oneOf": [
+      {
+        "type": "string"
+      },
+      {
+        "properties": {
+          "alt_text": {
+            "type": "string"
+          },
+          "file_path": {
+            "type": "string"
+          },
+          "render": {
+            "enum": [
+              "image",
+              "link",
+              "auto"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "file_path"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  "type": "array"
+}
    • removedInput schema / properties / description / description
      Removed value: -"New description (optional)"
    • removedInput schema / properties / destination_branch / description
      Removed value: -"New destination branch (optional)"
    • changedInput schema / properties / repository / description
      Previous value: -"Repository slug (e.g., \"my-repo\")"New value: +"Repository slug"
    • changedInput schema / properties / reviewers / description
      Previous value: -"New list of reviewer usernames/emails. If provided, replaces the reviewer list (preserving approval status for existing reviewers). If omitted, existing reviewers are preserved. (optional)"New value: +"Replaces reviewer list; approvals preserved"
    • removedInput schema / properties / title / description
      Removed value: -"New title (optional)"
    • addedInput schema / properties / version
      Added value: +{
+  "description": "Entity version from a prior read; supplying it saves a fetch AND makes the write conditional — it fails on concurrent modification instead of overwriting. Omit to write against the latest state (auto-retried once).",
+  "type": "number"
+}
    • changedInput schema / properties / workspace / description
      Previous value: -"Bitbucket workspace/project key (e.g., \"PROJ\")"New value: +"Project key (e.g., PROJ)"
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does so well: it explains that reviewers/approvals are preserved unless `reviewers` is passed, and that supplying `version` makes the write conditional and fails on concurrent modification. It still omits permission requirements and whether all fields are optional.

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?

Three short sentences, front-loaded with purpose and followed by the two highest-value behavioral caveats. No filler and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the trickiest fields (reviewers, version) but never mentions that title/description/destination_branch can be changed, nor whether the write is partial or full-replacement. It is adequate but leaves meaningful gaps.

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?

Schema coverage is 67% and the schema already documents `version`, `reviewers`, `attachments`, and the required identifiers. The description adds genuine cross-cutting meaning about the reviewer/approval interaction and the version fetch-save behavior, though title, description, and destination_branch remain unexplained in both places.

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?

States a specific verb+resource ('Update a pull request'), making it immediately distinguishable from create/merge/decline siblings. It does not explicitly name those siblings, but the mutation scope is clear.

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?

Gives conditional guidance on the `version` parameter (pass to save a fetch, or omit for auto-retry), which implies when each mode is appropriate. However, there is no explicit statement of when to use this tool versus alternatives like merge or set_review_status, and no prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools