Skip to main content
Glama
pdogra1299

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_pull_request

Retrieve a Bitbucket pull request's metadata, reviewer status, merge info, comments, and changed files; toggle includes for metadata-only reads.

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

TableJSON 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

A3.9/5.0
Behavior3/5

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

No annotations, so the description carries the full burden. It usefully discloses that the response carries `version` for follow-up mutations and explains the flag-driven payload options, but omits permissions/auth requirements, pagination behavior, and comment_limit semantics already hinted at only 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?

Two dense sentences, front-loaded with the core purpose, then the flag/behavior notes and the version field. Nothing is wasted.

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 and no annotations, the description adequately covers the returned payload categories, the key toggles, and the version field needed for mutation follow-ups. Minor gaps around auth and pagination keep it from being fully complete.

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, but the description adds real interpretive value: it explains the effect of include_comments/include_file_changes (a lean 1-call metadata read) and what include_tasks surfaces. Only comment_limit is left unexplained in prose.

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?

Specific verb (Get) + resource (pull request) with an enumeration of the returned data (metadata, reviewer status, merge info, comments, changed files). This distinguishes it from list_pull_requests and get_pull_request_diff without naming them, so it stops just short of explicit sibling routing.

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 concrete when-to-use guidance: set include_comments/include_file_changes false for a 1-call metadata read. It does not, however, explicitly name alternative tools (e.g., get_pull_request_diff for diffs) or state exclusions, so it lacks 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