Skip to main content
Glama
Sign In
Bitbucket MCP Server

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_pull_request

Idempotent

Update a pull request’s title, description, branch, reviewers, or attachments while preserving approvals unless replaced; pass version to avoid overwriting concurrent changes.

Instructions

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

Input 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.6/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds the operationally important partial-update semantics: reviewers and approvals survive unless `reviewers` is supplied. It still omits what happens to other omitted fields (title/description) and any permission or failure conditions beyond the version note.

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?

Three short sentences, front-loaded with the core action, then the two behavioral caveats. Slight redundancy with the parameter descriptions (reviewer preservation and version fetching are already in the schema), but nothing is padded or buried.

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 output schema, the definition covers the versioning and reviewer clobbering risks but leaves gaps: no statement of permission requirements, no mention of what the response contains, and no note that omitted fields are untouched. Adequate, but not complete enough to call without any further inference.

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?

At 67% schema coverage, the schema already documents the two most subtle parameters (`version` concurrency semantics, `reviewers` replacement). The description restates rather than extends these, and says nothing about `title`, `description`, `destination_branch`, or the Server/DC-only `attachments` caveat that sits only in the schema.

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?

Names a specific verb+resource (update a pull request) that is clearly distinguishable from read siblings like get_pull_request and list_pull_requests. However, it does not distinguish itself from mutating siblings such as merge_pull_request, decline_pull_request, or set_review_status, so the boundary is only partly drawn.

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 two concrete usage hints: pass `version` (from get/list) to avoid a fetch, and reviewers are preserved unless `reviewers` is passed. That is useful conditional guidance but only about parameters — there is no statement of when to choose this tool over merge/decline/set_review_status, and no prerequisites such as permissions.

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