Skip to main content
Glama
Sign In
mcp-server-bitbucket

mcp-server-bitbucket

by JaviMaligno
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

list_commits

Lists repository commits newest first without cloning, with include/exclude filters for branches, tags, or hashes and optional path scoping; follow the cursor to page through results.

Instructions

List a page of commits, newest first, without cloning.

include selects commits reachable from any supplied branch/tag/hash; exclude
removes commits reachable from those revisions. For commits in v2 but not v1,
use include=["v2"], exclude=["v1"]. branch is an additional include alias.
path restricts changes to a file/directory. Follow next_cursor until has_more
is false. cursor preserves its issued filters/page size; limit (1-100) and
filters apply only to the first page. Absence from one page is not absence
from repository history.

Input Schema

NameRequiredDescriptionDefault
pathNo
limitNo
branchNo
cursorNo
excludeNo
includeNo
repo_slugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Cursor"
+}
    • addedInput schema / properties / exclude
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Exclude"
+}
    • addedInput schema / properties / include
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Include"
+}
  2. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations present, the description carries the full load and does it well: it discloses ordering, pagination rules (cursor preserves filters and page size; limit and filters apply only to the first page), and an important caution that absence from one page is not absence from repository history. It doesn't state auth/permission requirements, which keeps it from a 5.

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?

Front-loaded with purpose and the most surprising semantics (reachability filtering) early, and every sentence adds information. It is dense to the point that pagination rules read as a run-on, but no sentence is expendable.

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 a 7-parameter read tool with no annotations and no output schema, the description covers filtering semantics, ordering, and pagination behavior, and incidentally reveals the next_cursor/has_more response fields. It stops short of describing commit record contents, but nothing needed to invoke it correctly is missing.

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 0%, so the description must compensate and largely does: it defines include, exclude, branch (as an include alias), path, cursor, and limit with a valid range of 1-100, plus the next_cursor/has_more loop. Only repo_slug is left implicit, which is a reasonable omission given it is required and self-named.

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?

States a specific verb and resource ("List a page of commits"), plus ordering ("newest first") and a distinguishing trait ("without cloning"). This clearly separates it from get_commit (single commit) and compare_commits (diff between revisions) without needing to name them.

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?

Explains the include/exclude reachability model with a concrete worked example (include=["v2"], exclude=["v1"]) and clarifies that branch is an alias for include and path scopes to a file/directory. It does not say when to prefer compare_commits or get_commit_diff instead, but the usage context for this tool is clear.

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