Skip to main content
Glama
pdogra1299

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_branch_commits

Retrieve commits from a specific Bitbucket branch, with filters for author, date, search terms, and merge commits. Supports pagination and build status inclusion.

Instructions

List commits on a branch. since (as a rev) and include_merge_commits filter server-side; author/until/search and date-valued since filter client-side over a bounded page walk (noted when more pages exist).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 25)
sinceNoISO date lower bound, or a commit SHA/ref (exclusive) for a server-side range
startNoPagination start (default 0)
untilNoISO date upper bound
authorNo
searchNoSubstring in commit message
workspaceYesProject key (e.g., PROJ)
repositoryYesRepository slug
branch_nameYes
include_build_statusNoServer only
include_merge_commitsNoDefault true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv3.0.1
    • removedInput schema / properties / author / description
      Removed value: -"Filter by author email/username (optional)"
    • removedInput schema / properties / branch_name / description
      Removed value: -"Branch name to get commits from"
    • addedInput schema / properties / include_build_status
      Added value: +{
+  "description": "Server only",
+  "type": "boolean"
+}
    • changedInput schema / properties / include_merge_commits / description
      Previous value: -"Include merge commits in results (default: true)"New value: +"Default true"
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of commits to return (default: 25)"New value: +"Max results (default 25)"
    • changedInput schema / properties / repository / description
      Previous value: -"Repository slug (e.g., \"my-repo\")"New value: +"Repository slug"
    • changedInput schema / properties / search / description
      Previous value: -"Search for text in commit messages (optional)"New value: +"Substring in commit message"
    • changedInput schema / properties / since / description
      Previous value: -"ISO date string - only show commits after this date (optional)"New value: +"ISO date lower bound, or a commit SHA/ref (exclusive) for a server-side range"
    • changedInput schema / properties / start / description
      Previous value: -"Start index for pagination (default: 0)"New value: +"Pagination start (default 0)"
    • changedInput schema / properties / until / description
      Previous value: -"ISO date string - only show commits before this date (optional)"New value: +"ISO date upper bound"
    • 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 full burden and does disclose non-obvious behavior: since-as-rev and include_merge_commits are filtered server-side, while author/until/search and date-valued since are filtered client-side over a bounded page walk. It also notes when more pages exist, which sets pagination expectations. It stops short of describing result shape or permission requirements.

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?

Two dense sentences with the core purpose front-loaded and no filler. The second sentence is information-packed but slightly compressed, packing four filter behaviors into one clause chain.

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?

For an 11-parameter read tool with no output schema, the description covers the filtering semantics that matter most and signals pagination. It could say more about the returned commit fields, but the operational behavior an agent needs to call it correctly is present.

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 already 82%, so the schema supplies most parameter meaning. The description still adds real value by clarifying the dual nature of `since` (rev means server-side, date means client-side) and the server-side treatment of include_merge_commits, resolving an ambiguity the schema leaves implicit.

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 and resource ("List commits on a branch"), which separates it from get_commit_detail and list_pr_commits by scope. However, it never explicitly contrasts itself with those siblings, so the differentiation is inferable rather than stated.

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?

The description explains which filters run server-side vs client-side, which implicitly tells the agent when a filter is cheap, but it offers no explicit when-to-use guidance or exclusions relative to siblings like list_pr_commits or get_commit_detail. Usage is implied by the branch-scoped framing.

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