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

mcp-server-bitbucket

by JaviMaligno
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

trigger_pipeline

Triggers a Bitbucket pipeline run on a repository branch or commit, including custom pipelines and pipeline variables.

Instructions

Trigger a pipeline run on a repository.

Supports custom pipelines (from 'custom:' section in bitbucket-pipelines.yml)
and commit-based triggers.

Args:
    repo_slug: Repository slug
    branch: Branch to run pipeline on (default: main). Mutually exclusive with commit.
    commit: Commit hash to run pipeline on. Mutually exclusive with branch.
    custom_pipeline: Name of custom pipeline from 'custom:' section
                    (e.g., "deploy-staging", "dry-run")
    variables: Pipeline variables as list of {key, value, secured?} objects.
              Example: [{"key": "ENV", "value": "prod", "secured": false}]

Returns:
    Pipeline run info with uuid and state

Examples:
    # Default branch pipeline
    trigger_pipeline(repo_slug="my-repo")

    # Custom pipeline
    trigger_pipeline(repo_slug="my-repo", custom_pipeline="deploy-staging")

    # Custom pipeline on specific commit
    trigger_pipeline(repo_slug="my-repo", commit="abc123", custom_pipeline="dry-run")

    # With secured variables
    trigger_pipeline(repo_slug="my-repo", variables=[
        {"key": "ENV", "value": "prod"},
        {"key": "SECRET", "value": "xxx", "secured": true}
    ])

Input Schema

NameRequiredDescriptionDefault
branchNo
commitNo
repo_slugYes
variablesNo
custom_pipelineNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / branch / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / branch / default
      Previous value: -"main"New value: +null
    • removedInput schema / properties / branch / type
      Removed value: -"string"
    • addedInput schema / properties / commit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Commit"
+}
    • addedInput schema / properties / custom_pipeline
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Custom Pipeline"
+}
    • changedInput schema / properties / variables / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the whole burden. It does disclose the return shape (pipeline run info with uuid and state), which is valuable because there is no output schema, but it says nothing about required permissions, whether the trigger is async, what happens on an invalid branch/commit pair, or the real-world consequence of starting a deployment pipeline.

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?

The Args/Returns/Examples layout is front-loaded and scannable, and each example demonstrates a distinct argument combination. The four examples are slightly redundant with the Args block for the variable case, keeping it just short of a 5.

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 five-parameter mutation tool with no annotations and no output schema, the description covers purpose, arguments, return value, and usage patterns, which is enough to call it correctly. Missing are permission prerequisites and failure behaviour, which matter for a pipeline-triggering side effect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does: every one of the five parameters is explained, including defaults, the branch/commit mutual exclusion, and the exact {key, value, secured} shape of variables. The worked examples reinforce the variable format with a secured entry.

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 first line gives a specific verb plus resource ("Trigger a pipeline run on a repository") and the follow-up narrows the scope to custom pipelines and commit-based triggers. An agent can distinguish it from stop_pipeline and list_pipelines without opening any schema.

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?

It clearly states the mutually exclusive branch/commit constraint, the default of main, and where custom pipeline names come from, so the agent knows which argument combination to pick. It never routes to alternatives such as list_pipelines to verify a run started or stop_pipeline to cancel, so it stops short of full sibling 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