Skip to main content
Glama
jacobpixleratgather

bitbucket-mcp

by jacobpixleratgather
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get PR diff

get_pr_diff
Read-onlyIdempotent

Fetch the unified diff for a pull request, with options to view file stats first or limit output to specific paths and sizes.

Instructions

Fetch the unified diff for a pull request. For a large PR, start with stat_only: true to see which files changed and how big the diff is, then pass paths to fetch only the parts you need. Output is capped at max_bytes (default 100 KB) and the tail is dropped with a note when it overflows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoBitbucket repo slug.
pathsNoLimit the diff to these files or directories (repo-relative; a directory matches everything under it).
pr_idNoPull request id.
max_bytesNoMaximum diff bytes to return. Default 100000.
stat_onlyNoReturn a per-file summary (status, lines added/removed) plus totals instead of the diff text.
workspaceNoBitbucket workspace (slug).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.6
    • addedInput schema / properties / max_bytes
      Added value: +{
+  "description": "Maximum diff bytes to return. Default 100000.",
+  "maximum": 5000000,
+  "minimum": 1000,
+  "type": "integer"
+}
    • addedInput schema / properties / paths
      Added value: +{
+  "description": "Limit the diff to these files or directories (repo-relative; a directory matches everything under it).",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / stat_only
      Added value: +{
+  "description": "Return a per-file summary (status, lines added/removed) plus totals instead of the diff text.",
+  "type": "boolean"
+}
  2. First observedv0.1.5

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false), the description reveals two important behaviors: the output is capped at max_bytes and the tail is dropped with a note when it overflows, and stat_only:true returns a per-file summary instead of the diff text. These are critical user-facing traits that are not inferable from annotations alone.

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 two sentences with zero wasted words. The first sentence states the core purpose; the second provides actionable usage guidance and a critical limiter (max_bytes). Information is front-loaded and every sentence adds value.

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 has six optional parameters, no output schema, and no nested objects, the description covers most concerns an agent would have: how to avoid large diffs, the cap and its effect, and the distinction between summary and full diff. It doesn't detail the exact format of the stat_only summary, but that's a minor gap. The absence of required parameters is addressed indirectly by the tool's design, though not explicitly clarified.

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?

The schema already fully describes all six parameters (100% coverage), so the baseline is 3. However, the description adds meaning beyond the schema by explaining how to combine stat_only and paths for large PRs (a workflow) and by noting the default max_bytes. It gives practical guidance on parameter usage, justifying a slight bump.

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 opens with a specific verb and resource: 'Fetch the unified diff for a pull request.' This clearly states the tool's function and distinguishes it from sibling tools like get_pr (which retrieves PR metadata) and list_prs (which lists PRs). The scope 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on how to handle large PRs: start with stat_only:true, then use paths to fetch specific parts. It also mentions the max_bytes cap and tail-drop behavior, which are practical usage constraints. It does not name alternative tools because no direct alternative exists, but the provided strategy is clear and actionable.

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