bitbucket-pr-review-mcp

Ein MCP-Server, der es einem Sprachmodell ermöglicht, einen Bitbucket-Cloud-Pull-Request zu lesen und Kommentare dazu zu hinterlassen – verankert an den Zeilen, um die es geht, plus eine Zusammenfassung oben.

Der Server liefert Material und veröffentlicht Wörter. Er bildet keine Meinungen: Das aufrufende Modell übernimmt die Überprüfung, und nichts hier enthält einen Review-Prompt oder eine Modell-Anmeldeinformation.

• So funktioniert es und warum: docs/architecture.md

• Die Entscheidungen dahinter: docs/adr/

• Die Sprache, die es verwendet: CONTEXT.md

Was es nicht kann

Es kann Kommentare erstellen und aktualisieren. Es kann einen Pull-Request nicht genehmigen, ablehnen oder zusammenführen, kann nicht in Branches oder Dateien schreiben und löscht niemals einen Kommentar.

Bitbucket verkauft keine Berechtigung, die Kommentieren vom Zusammenführen trennt. Die Anmeldeinformation, die Sie diesem Server geben, kann Ihre Pull-Requests zusammenführen; nichts an Tokens oder Scopes verhindert das. Was es verhindert, ist, dass kein Tool danach fragt, dass ein einzelner Engpass im HTTP-Client es ablehnt, egal wie die Anfrage konstruiert ist, und – der Teil, der nicht davon abhängt, dass dieser Code korrekt ist – Branch-Restriktionen, die Sie selbst im Repository konfigurieren. Siehe ADR-0002 und lesen Sie Bevor Sie beginnen.

Related MCP server: Bitbucket MCP Server

Bevor Sie beginnen

Konfigurieren Sie Branch-Restriktionen für jedes Repository, das Sie auf die Whitelist setzen. In Bitbucket: Repository-Einstellungen → Branch-Restriktionen. Beschränken Sie, wer in Ihren Standard-Branch zusammenführen darf, und verlangen Sie die Genehmigungen, die Ihr Team erwartet. Bitbucket setzt das durch, unabhängig davon, was dieser Server tut, was es zur einzigen Garantie hier macht, die einen Fehler in diesem Repository überlebt. Es dauert eine Minute und es ist der Unterschied zwischen „wir glauben, dieser Code ist vorsichtig“ und „es spielt keine Rolle, ob er es ist“.

Installation

Erfordert uv und Python 3.13. Die gleichen drei Befehle funktionieren unter Windows, macOS und Linux:

git clone <this repository>
cd bitbucket-pr-review-mcp
uv sync

Dann teilen Sie ihm mit, welche Repositorys es berühren darf:

cp config/repositories.yaml.example config/repositories.yaml

...und bearbeiten Sie es. Die Datei listet workspace/repo-Einträge auf, enthält keine Geheimnisse und soll committet werden:

repositories:
  - streamstech/db-explorer
  - streamstech/lent-manager

Ein gesamter Workspace kann als jantrik/* geschrieben werden. Es ist der breiteste Eintrag hier – er deckt Repositorys ab, die nach dem Schreiben erstellt werden –, daher sagt der Server das bei jedem Start:

repositories:
  - jantrik/*

Der Server weigert sich, ohne eine Liste zu starten. Eine fehlende Liste ist nicht von der Erlaubnis zu unterscheiden, jedes Repository zu berühren, das Ihre Anmeldeinformation erreichen kann. Muster, die enger als ein gesamter Workspace sind (*/db-explorer, streamstech/db-*), werden aus demselben Grund abgelehnt: Sie sind Vermutungen über die Benennung und nehmen alles auf, was als Nächstes so benannt wird.

Verbinden Ihres Bitbucket-Kontos

Führen Sie das Setup aus und öffnen Sie den Link, den es ausgibt:

uv run bb-pr-mcp --setup

Es stellt eine Seite auf Ihrem eigenen Rechner bereit – nur Loopback, auf einem zufälligen Port, Einmal-Link, nach fünf Minuten verschwunden – und fragt nach Ihrer Atlassian-Konto-E-Mail (nicht Ihrem Bitbucket-Benutzernamen und nicht dem Namen, den Sie dem Token gegeben haben) und einem API-Token. Es überprüft das Paar gegen Bitbucket und zeigt Ihren Anzeigenamen an, bevor es etwas speichert, dann legt es die Anmeldeinformation in Ihren OS-Schlüsselbund und schließt sich.

Erstellen Sie das Token unter https://id.atlassian.com/manage-profile/security/api-tokens mit genau diesen vier Bereichen:

Nichts Breiteres. Ein Token, das auch in ein Repository schreiben, eines verwalten oder Pipelines ausführen kann, wird im Formular abgelehnt und beim Start erneut abgelehnt.

Geben Sie das Ablaufdatum des Tokens bei der Einrichtung ein, und Sie werden eine Woche vor Ablauf gewarnt, anstatt mitten in der Überprüfung auf einen 401 zu stoßen.

Sie müssen --setup nie explizit ausführen: Wenn keine Anmeldeinformation gespeichert ist, antwortet jedes Tool mit der Setup-URL statt mit einem Fehler.

Überprüfen Sie es, wann immer Sie möchten:

uv run bb-pr-mcp --check

Das validiert die Whitelist, die Anmeldeinformation und ihre Bereiche, gibt aus, als wer Sie posten, und beendet sich mit einem Shell-Status – 0 in Ordnung, 1 keine verwendbare Anmeldeinformation, 2 ein Token mit falschen Bereichen.

Entfernen

uv run bb-pr-mcp --forget

Das löscht die Anmeldeinformation aus dem Schlüsselbund dieses Geräts und sonst nichts – das Token existiert weiterhin bei Atlassian, bis Sie es dort widerrufen, und der Befehl sagt das. Der nächste Tool-Aufruf gibt Ihnen einen frischen Setup-Link.

Es gibt bewusst kein Tool dafür. Ein Tool, das die Anmeldeinformation löscht, ist ein Tool, zu dessen Aufruf eine Pull-Request-Beschreibung ein Modell überreden kann, und nichts wird gewonnen: Wer es loswerden will, sitzt bereits an einem Terminal.

Das Modell sieht das Token nie

Das Token geht von Ihrem Browser in den Schlüsselbund und von dort in einen Authorization-Header. Es ist nie ein Argument für ein Tool, nie in der Antwort eines Tools, nie in einer Fehlermeldung und nicht in der Setup-URL – diese trägt ein anderes Einmal-Token, das nichts gewährt außer dem Recht, ein Formular auf diesem Rechner auszufüllen. tests/test_the_token_never_reaches_the_model.py sucht an all diesen Stellen danach.

Wenn der Schlüsselbund nicht verfügbar ist

Die Anmeldeinformation kommt in den OS-Schlüsselbund und sonst nirgendwo hin – nie in eine Datei. Unter macOS und Windows funktioniert das sofort. Unter Linux benötigen Sie einen laufenden und entsperrten Secret Service (gnome-keyring oder KWallet); wenn es keinen gibt, stoppt der Server, anstatt auf eine Datei zurückzugreifen (ADR-0003).

Ausführen

Der Server spricht MCP über stdio. Richten Sie Ihren Client darauf aus:

{
  "mcpServers": {
    "bitbucket-pr-review": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/bitbucket-pr-review-mcp", "bb-pr-mcp"]
    }
  }
}

Unter Windows verwenden Sie dieselbe Form mit einem Windows-Pfad ("C:\\path\\to\\bitbucket-pr-review-mcp"). Sonst unterscheidet sich nichts zwischen den Plattformen.

Für Claude Code:

claude mcp add bitbucket-pr-review -- uv run --directory /path/to/bitbucket-pr-review-mcp bb-pr-mcp

Ausführen in Docker

Das Image spricht MCP über stdio wie alles andere, daher gibt es keinen Port und nichts zu up. Bauen Sie es, dann führen Sie es mit -i aus und sprechen Sie mit ihm.

docker build -t bitbucket-pr-review-mcp:local .

Ein Container hat keinen Schlüsselbund, und die Setup-Seite kann nicht helfen: Sie bindet einen Loopback-Port innerhalb des Containers, den Ihr Browser nicht erreichen kann. Ein containerisierter Lauf bekommt seine Anmeldeinformation also gegeben, statt eine zu speichern. Das ist eine echte Herabstufung – eine Umgebungsvariable ist für docker inspect und für alles, was den Prozess lesen kann, sichtbar – und es ist eine Entscheidung und kein Fallback: Nichts degradiert hinein, beide Variablen müssen gesetzt sein, und der Start sagt das jedes Mal. Siehe ADR-0007.

Legen Sie die Anmeldeinformation in eine Datei, die nicht in diesem Repository liegt:

BB_MCP_EMAIL=you@yourcompany.com
BB_MCP_API_TOKEN=ATATT...
BB_MCP_TOKEN_EXPIRES_ON=2027-08-24

Dann überprüfen Sie es und binden Sie es in einen Client ein:

docker run --rm \
  --env-file /path/to/env.docker \
  -v /path/to/repositories.yaml:/config/repositories.yaml:ro \
  bitbucket-pr-review-mcp:local --check

{
  "mcpServers": {
    "bitbucket-pr-review": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "--env-file", "/path/to/env.docker",
        "-v", "/path/to/repositories.yaml:/config/repositories.yaml:ro",
        "bitbucket-pr-review-mcp:local"
      ]
    }
  }
}

docker-compose.yaml schreibt dieselben Flags einmal auf: docker compose run --rm bitbucket-pr-review, wobei .env.docker (gitignored) aus diesem Verzeichnis gelesen wird.

Ein paar Dinge, die es wert sind zu wissen:

• Unter Windows verwenden Sie einen Windows-Stil-Pfad in -v (d:/path/to/repositories.yaml:/config/...). Unter Git Bash stellen Sie dem Befehl MSYS_NO_PATHCONV=1 voran, sonst wird der Pfad umgeschrieben.

• Die Whitelist wird gemountet, nicht eingebacken. Sie benennt die Repositorys, die der Server berühren darf; diese Liste gehört dem, der das Image ausführt, nicht dem Image.

• --setup beendet sich in einem Container mit 2 und sagt, wo das Setup stattdessen ausgeführt werden kann. Das Rotieren eines Tokens bedeutet einen Neustart mit einem neuen.

• Der Container läuft als Nicht-Root-Benutzer, schreibgeschützt, mit allen Capabilities entfernt.

Verbinden mit dem gemeinsamen Server

Die gemeinsame Bereitstellung – mehrere Personen, ein Server, jeder mit seinem eigenen Bitbucket-Konto – läuft hinter einer einzigen Origin. Sowohl der MCP-Endpunkt als auch Keycloak werden von dort bereitgestellt, weil der Issuer eine Zeichenfolge ist, die im Token, im Discovery-Dokument, im Browser und in der Konfiguration dasselbe bedeuten muss.

Weder Claude Desktop noch Claude Code erreichen den Server direkt über localhost. Ein Claude Custom Connector wird von der Infrastruktur von Anthropic abgerufen, nicht von Ihrem Rechner, daher ist ein Server auf Ihrem Laptop unerreichbar, egal wie er konfiguriert ist. Die lokale Schleife geht über mcp-remote: eine stdio-Brücke, die auf Ihrem Rechner läuft, den OAuth-Flow in Ihrem Browser durchführt und HTTP mit dem Server spricht. Sobald der Server eine öffentliche https-Adresse hat, erreicht ein Custom Connector ihn direkt und die Brücke wird nicht mehr benötigt.

Welche Client-ID wohin gehört

Der Realm enthält drei OAuth-Clients, weil drei verschiedene Dinge authentifizieren, und sie sind nicht austauschbar. Die Verwendung des falschen scheitert am ersten Schritt, mit Invalid parameter: redirect_uri auf einer Keycloak-Fehlerseite – die den Parameter statt des Clients benennt und für jede Ursache dieselbe Meldung ist.

Die Aufteilung folgt dem Ort, an dem der Callback landet. Der Callback eines Connectors ist https://claude.ai/api/mcp/auth_callback, auf der Infrastruktur von Anthropic, daher ist dieser Client vertraulich und sein Geheimnis lebt dort. Der Callback der Brücke ist ein Loopback-Port auf dem Laptop von jemandem, daher hält dieser Client überhaupt kein Geheimnis – ein Geheimnis in einer Konfigurationsdatei auf einem Laptop ist kein Geheimnis, und PKCE schützt einen Loopback-Flow. Die Registrierung des gehosteten Callbacks auf dem öffentlichen Client würde den vertraulichen Flow einem Client übergeben, der nichts behalten kann, daher ist er nicht registriert, und Keycloak lehnt ihn ab.

Kopieren Sie .env.example nach .env und starten Sie es dann:

cp .env.example .env      # fill in the secrets; the defaults are the loopback stack
docker compose --profile shared up -d

Das bringt Postgres, Keycloak, nginx und den Review-Server hoch. docker compose --profile shared ps sollte vier gesunde Container zeigen, und http://localhost:8080/mcp sollte mit 401 und einem WWW-Authenticate-Header antworten, der den bitbucket:review-Bereich nennt – eine nicht authentifizierte Anfrage, die abgelehnt wird, ist das System, das funktioniert.

Claude Code

Registrieren Sie die Brücke einmal, für jedes Projekt, mit -s user:

claude mcp add bitbucket-pr-review -s user -- npx -y mcp-remote http://localhost:8080/mcp 3334 --allow-http --static-oauth-client-info "{\"client_id\":\"bitbucket-pr-review-cli\"}"

-s user schreibt es in den Top-Level-mcpServers-Schlüssel in ~/.claude.json, der in jedem Verzeichnis gilt. Die Alternativen sind -s local (nur dieses Projekt, ebenfalls in ~/.claude.json, unter projects) und -s project (eine committete .mcp.json). Registrieren Sie es nicht in mehr als einem Bereich: Die Konfigurationen sind getrennt, der Benutzerbereich gewinnt, und die, die Sie später bearbeiten, ist möglicherweise nicht die, die verwendet wird.

Überprüfen Sie es:

claude mcp get bitbucket-pr-review

Das sollte Scope: User config und Status: ✔ Connected melden. Eine Sitzung übernimmt MCP-Server beim Start, daher sieht ein bereits laufendes Claude Code einen neu registrierten Server erst nach einem Neustart.

Jemandem ein Konto geben

Der Realm wird mit einem Benutzer ausgeliefert, dev / dev-only-not-for-production, der eine Entwicklungs-Anmeldeinformation ist und das sagt. Alle anderen benötigen ein Konto in Keycloak, bevor sie sich anmelden können – das ist getrennt von der späteren Verbindung ihres Bitbucket-Kontos, die sie selbst unter /connect durchführen.

In der Administrationskonsole. Öffnen Sie http://localhost:8080/admin, melden Sie sich als Bootstrap-Administrator an (KC_BOOTSTRAP_ADMIN_USERNAME / KC_BOOTSTRAP_ADMIN_PASSWORD aus Ihrer .env-Datei), wechseln Sie die Realm-Auswahl von master zu streamstech, dann Benutzer → Benutzer hinzufügen. Füllen Sie Benutzername, E-Mail, Vorname und Nachname aus, aktivieren Sie E-Mail verifiziert und erstellen Sie den Benutzer. Dann Anmeldedaten → Passwort festlegen und Temporär deaktivieren, es sei denn, Sie möchten, dass sie beim ersten Login zur Änderung aufgefordert werden.

Oder über die Befehlszeile, was sich leichter wiederholen lässt:

docker exec bitbucket-pr-review-mcp-keycloak-1 /opt/keycloak/bin/kcadm.sh \
  config credentials --server http://localhost:8080 --realm master \
  --user admin --password "$KC_BOOTSTRAP_ADMIN_PASSWORD"

docker exec bitbucket-pr-review-mcp-keycloak-1 /opt/keycloak/bin/kcadm.sh \
  create users -r streamstech \
  -s username=somebody -s email=somebody@example.com -s emailVerified=true \
  -s firstName=Some -s lastName=Body -s enabled=true

docker exec bitbucket-pr-review-mcp-keycloak-1 /opt/keycloak/bin/kcadm.sh \
  set-password -r streamstech --username somebody --new-password 'their-password'

Unter Git Bash stellen Sie jedem dieser Befehle MSYS_NO_PATHCONV=1 voran, sonst wird /opt/keycloak/... in einen Windows-Pfad umgeschrieben und docker exec meldet, dass die Datei nicht existiert.

Zwei Dinge sind leicht falsch zu machen, und beide scheitern beim Login und nicht bei der Erstellung, mit einer Meldung, die nicht auf die Ursache hinweist:

• Vorname und Nachname sind erforderlich. Das Benutzerprofil von Keycloak behandelt sie als Pflichtfelder, sodass sich ein Konto, das ohne sie erstellt wurde, mit invalid_grant: Account is not fully set up anmeldet. Beim Erstellen des Kontos warnt nichts.

• kcadm.sh set-password ohne -t ist bereits permanent; die Übergabe von -t macht es temporär und lässt dieselbe erforderliche Aktion offen.

Keine Rollen oder Gruppenmitgliedschaften sind erforderlich. Ein neues Konto erhält automatisch default-roles-streamstech, und das reicht aus – dieser Server autorisiert auf dem Scope bitbucket:review, der während des OAuth-Flows angefordert und zugestimmt wird, nicht im Voraus gewährt.

Konten leben in der Datenbank von Keycloak, die ein Volume ist. Sie überleben Neustarts, aber nicht docker volume rm bitbucket-pr-review-mcp_keycloak-db.

Claude Desktop

Claude Desktop hat keinen mcp add-Befehl; Sie bearbeiten claude_desktop_config.json von Hand. Wo sich die Datei befindet, hängt von der Installation von Claude ab:

Der Store-Pfad ist derjenige, der Leute reinlegt – eine Installation aus dem Store ignoriert die %APPDATA%-Datei vollständig, und das Bearbeiten der falschen Datei ändert nichts, ohne eine Fehlermeldung.

{
  "mcpServers": {
    "bitbucket-pr-review": {
      "command": "cmd",
      "args": [
        "/c", "npx",
        "-y", "mcp-remote",
        "http://localhost:8080/mcp",
        "3335",
        "--allow-http",
        "--static-oauth-client-info", "{\"client_id\":\"bitbucket-pr-review-cli\"}"
      ]
    }
  }
}

deploy/claude_desktop_config.example.json enthält dasselbe. Zwei Details darin leisten echte Arbeit:

• cmd /c vor npx unter Windows. Claude Desktop startet nicht über eine Shell, daher löst ein nacktes "command": "npx" eine Batch-Datei auf, deren eigener Pfad ein Leerzeichen enthält, und das Ganze stirbt mit 'C:\Program' is not recognized as an internal or external command im Protokoll darunter. Unter macOS entfernen Sie cmd und /c und verwenden "command": "npx".

• Port 3335 statt 3334. Diese Nummer ist der eigene Loopback-Port der Brücke, und die Registrierung von Claude Code verwendet bereits 3334. Zwei Brücken auf einem Port bedeuten, dass die zweite startende Brücke ihren OAuth-Callback nicht empfangen kann. Die Realm registriert http://127.0.0.1:*/oauth/callback, daher funktioniert jeder freie Port.

Starten Sie Claude Desktop neu – vollständig, über das Tray, da das Schließen des Fensters es weiterlaufen lässt – und prüfen Sie, ob es gestartet ist:

tail -f "$LOCALAPPDATA/Packages/Claude_*/LocalCache/Roaming/Claude/logs/mcp-server-bitbucket-pr-review.log"

Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport ist die Zeile, die bedeutet, dass die Brücke mit dem Server spricht. Server transport closed unexpectedly bedeutet, dass sie stattdessen beendet wurde – der Grund steht ein paar Zeilen darüber.

Der erste Tool-Aufruf öffnet dann ein Keycloak-Login (dev / dev-only-not-for-production in der Entwicklungsrealm oder ein Konto, das Sie oben erstellt haben). Nach der Anmeldung antwortet ein Tool-Aufruf mit einem Link zu /connect, wo Sie Ihr Atlassian-Konto verbinden – diese Seite lässt den Browser ebenfalls anmelden, weshalb der Link sicher in einem Transkript zu sehen ist.

Ein paar Dinge, die man wissen sollte:

• Die Brücke ist ein öffentlicher OAuth-Client ohne Geheimnis. Ein Client-Secret in einer Konfigurationsdatei auf einem Laptop ist kein Geheimnis; PKCE schützt einen Loopback-Flow.

• Ihr Callback ist http://127.0.0.1:3334/oauth/callback – die IP-Literal statt localhost und /oauth/callback statt Claude Codes /callback. Die Realm registriert alle, weil ein Fehler beim letzten Schritt des Flows scheitert.

• --allow-http ist erforderlich, solange der Server auf einfachem http läuft. Eine echte Bereitstellung ist https, und dieser Server weigert sich, sich über http außerhalb von Loopback zu beschreiben.

• Das Argument 3334 ist der eigene Port der Brücke, und die Realm registriert den Callback darauf. Zwei gleichzeitige Claude-Clients, die brücken, benötigen verschiedene Ports.

• Die Defaults des shared-Profils sind Entwicklungs-Konfiguration – ein Bootstrap-Administrator, dessen Passwort in docker-compose.yaml steht, eine Realm mit einem Benutzer, dessen Passwort in der Realm-Datei steht, und einfaches http auf Loopback. Jedes davon ist eine Variable mit einem Default, sodass eine echte Bereitstellung sie in .env überschreibt, anstatt eine der Dateien zu bearbeiten. Siehe docs/deploying-the-shared-server.md.

• Das Ändern der Herkunft erfordert den erneuten Import der Realm. Die Realm wird einmal in die Datenbank von Keycloak importiert; --import-realm lässt eine bestehende Realm in Ruhe. Entfernen Sie dieses Volume per Namen – docker volume rm bitbucket-pr-review-mcp_keycloak-db – und niemals down -v, das den Anmeldedaten-Tresor mitnehmen würde.

Betrieb

uv run bb-pr-mcp --health
uv run bb-pr-mcp --rotate-key /path/to/new.key

--health gibt an, ob die Bereitstellung lauffähig ist – TLS, der Tresorschlüssel, der Store, die Whitelist, ob der Autorisierungsserver erreichbar ist und wie viele Personen verbunden sind – und beendet sich mit 0 für gesund, 1 für etwas, das man sich ansehen sollte, 2 für „das wird nicht starten“.

--rotate-key versiegelt jede gespeicherte Anmeldeinformation unter einem neuen Schlüssel neu, ohne dass sich jemand erneut anmelden muss, und teilt Ihnen dann die Reihenfolge für den Rest mit.

Lesen Sie docs/deploying-the-shared-server.md, bevor Sie das irgendwo real ausführen. Es beschreibt, was ein einzelner Kompromittierung des Hosts kostet, was größer ist, als es aussieht, und was man dagegen tun kann.

Wer ist verbunden und wie man jemanden entfernt

uv run bb-pr-mcp --who
uv run bb-pr-mcp --revoke alice@streamstech.com

--who listet alle Personen auf, die ein Bitbucket-Konto verbunden haben: die undurchsichtige ID, die Atlassian-E-Mail, wann sie sich verbunden haben und wann ihr Token abläuft. Es entschlüsselt den Tresor, um zu antworten, und druckt dann alles außer dem einen Feld, für das sich die Entschlüsselung lohnt.

--revoke löscht die gespeicherten Anmeldedaten einer Person. Es akzeptiert eine E-Mail oder genug von der undurchsichtigen ID, um eindeutig zu sein, und weigert sich, anstatt zu raten, wenn ein Name zwei Personen entspricht. Der Widerruf wirkt beim nächsten Tool-Aufruf, auch auf einem Server, der bereits läuft – der gemeinsame Server liest die Anmeldedaten durch, anstatt sie zu halten, genau damit ein Operator in einem anderen Terminal nicht auf einen Neustart warten muss.

Was es nicht tut, ist der Teil, der lesenswert ist. Drei Stellen enthalten etwas, nachdem jemand gegangen ist, und dieser Befehl gehört zu einer davon:

• Hier. Die gespeicherte Anmeldeinformation ist weg.

• Keycloak. Sie können sich immer noch anmelden und ein neues Token verbinden. Deaktivieren Sie ihr Konto dort, um das zu stoppen.

• Atlassian. Ihr API-Token existiert weiterhin und funktioniert überall sonst weiter. Nur sie oder ein Atlassian-Administrator können es widerrufen.

Der Befehl nennt jedes Mal alle drei, weil eine Offboarding-Checkliste, die nach Schritt eins abgehakt wird, schlimmer ist als keine Checkliste.

Beides ist kein Tool, und das ist beabsichtigt: Eine Pull-Request-Beschreibung darf einen Caller nicht dazu überreden können, einen Kollegen zu trennen.

Die Tools

Ein Pull-Request wird durch eine Zeichenkette benannt: entweder eine Bitbucket-URL oder die Kurzform workspace/repo/id.

Konfiguration

Alles unten hat einen funktionierenden Standardwert. Sie können sie in der Umgebung oder in einer .env-Datei setzen, alle mit dem Präfix BB_MCP_:

Zwei weitere existieren und sind leer, bis die freigegebene Bereitstellung abgeschlossen ist – die oben beschriebene Installation pro Gerät benötigt keines von beiden, weil stdio genau einen Aufrufer hat:

Jede Obergrenze wird in der Antwort genannt, wenn sie zuschlägt. Eine Kürzung ist nie stillschweigend: Ein Aufrufer, der einen abgeschnittenen Diff nicht von einem vollständigen unterscheiden kann, wird die fehlende Hälfte prüfen, indem er annimmt, dass sie in Ordnung war.

Entwicklung

uv run pytest                    # the suite
uv run pytest --cov=src          # with coverage
uv run ruff check src tests      # lint
uv run ruff format src tests     # format

Tests berühren niemals das Netzwerk. Die Nahtstelle ist der HTTP-Transport und sonst nichts, sodass der Wächter, die Zulassungsliste und jeder Antwortleser wie Produktionscode ausgeführt werden. tests/recorded/ enthält Antworten, die von einem echten Pull-Request erfasst wurden – siehe docs/architecture.md, warum das wichtiger ist, als es klingt.