Skip to main content
Glama
Sign In
Bitbucket MCP Server

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_pull_request

Read-only

Retrieve pull request metadata, reviewer status, merge info, comments, and changed files for code review or follow-up changes. Disable comments and file changes for a metadata-only read.

Instructions

Get a pull request: metadata, reviewer status, merge info, comments and changed files. Set include_comments/include_file_changes false for a 1-call metadata read; include_tasks lists open/resolved tasks. Response carries version for follow-up mutations.

Input Schema

NameRequiredDescriptionDefault
workspaceYesProject key (e.g., PROJ)
repositoryYesRepository slug
comment_limitNoMax comments embedded (default 20)
include_tasksNoEmbed PR tasks (Server only, default false)
pull_request_idYesPull request ID
include_commentsNoEmbed active comments (default true)
include_file_changesNoEmbed changed-file list (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv3.0.1
    • addedInput schema / properties / comment_limit
      Added value: +{
+  "description": "Max comments embedded (default 20)",
+  "type": "number"
+}
    • addedInput schema / properties / include_comments
      Added value: +{
+  "description": "Embed active comments (default true)",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_file_changes
      Added value: +{
+  "description": "Embed changed-file list (default true)",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_tasks
      Added value: +{
+  "description": "Embed PR tasks (Server only, default false)",
+  "type": "boolean"
+}
    • changedInput schema / properties / repository / description
      Previous value: -"Repository slug (e.g., \"my-repo\")"New value: +"Repository slug"
    • 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

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely new behavioral context: the response carries `version` for follow-up mutations (optimistic concurrency), defaults are togglable for a single-call metadata read, and include_tasks is Server-only. It does not describe pagination behavior for comments beyond the schema's default.

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?

Two dense sentences, zero filler. Content discovery is front-loaded, followed by the cost-saving mode and the `version` follow-up hint, which is an efficient ordering for an agent scanning for both payload shape and next-step affordance.

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?

With no output schema, seven parameters and heavy return payload, the description does enough: it names the payload sections and flags the `version` field agents need for mutations. It leaves return-shape structure and comment pagination unstated, which is a modest remaining gap for a read this rich.

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 100%, so the baseline is 3. The description earns a notch above by explaining the effect of the two include_* flags (a cheaper metadata-only read) and clarifying that include_tasks surfaces open/resolved tasks rather than a raw boolean, which the schema does not convey.

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?

A specific verb-plus-resource opener ('Get a pull request') immediately followed by an enumeration of what comes back: metadata, reviewer status, merge info, comments, changed files. That enumeration distinguishes it from list_pull_requests, but the relationship to get_pull_request_diff is left implicit.

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?

Gives actionable usage direction: 'Set include_comments/include_file_changes false for a 1-call metadata read' tells the agent exactly how to switch into a cheap mode. It never names an alternative tool or an exclusion case (e.g. when to prefer get_pull_request_diff), so it stops short of full routing guidance.

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