bitbucket-pr-review-mcp

언어 모델이 Bitbucket Cloud 풀 리퀘스트를 읽고 그에 대한 코멘트를 남길 수 있게 해주는 MCP 서버 — 코멘트는 해당하는 코드 라인에 앵커링되며, 상단에 요약 코멘트 하나가 추가됩니다.

이 서버는 자료를 제공하고 글을 게시합니다. 의견을 형성하지는 않습니다: 리뷰를 수행하는 것은 호출하는 모델이며, 여기에는 리뷰 프롬프트나 모델 자격 증명이 포함되어 있지 않습니다.

• 작동 방식과 이유: docs/architecture.md

• 그 뒤에 있는 결정들: docs/adr/

• 사용하는 언어: CONTEXT.md

할 수 없는 것

코멘트를 생성하고 업데이트할 수 있습니다. 풀 리퀘스트를 승인, 거절 또는 병합할 수 없으며, 브랜치나 파일에 쓸 수 없고, 코멘트를 삭제하지도 않습니다.

Bitbucket은 코멘트 작성과 병합을 분리하는 권한을 판매하지 않습니다. 이 서버에 제공하는 자격 증명은 풀 리퀘스트를 병합할 수 있는 권한을 가집니다. 토큰이나 스코프로 이를 막을 수는 없습니다. 이를 막는 것은 어떤 도구도 병합을 요청하지 않는다는 점, HTTP 클라이언트의 단일 체크포인트가 요청이 어떻게 구성되든 이를 거부한다는 점, 그리고 — 이 코드가 올바르다는 것에 의존하지 않는 부분 — 리포지토리에서 직접 구성하는 브랜치 제한입니다. ADR-0002를 참조하고, 시작하기 전에를 읽어보세요.

Related MCP server: Bitbucket MCP Server

시작하기 전에

허용 목록에 포함하는 모든 리포지토리에 브랜치 제한을 구성하세요. Bitbucket에서: Repository settings → Branch restrictions. 기본 브랜치에 병합할 수 있는 사람을 제한하고, 팀이 기대하는 승인을 요구하세요. Bitbucket은 이 서버가 무엇을 하든 이를 강제하므로, 이 저장소의 버그가 발생해도 살아남는 유일한 보장입니다. 1분이면 되며, "이 코드가 신중하다고 믿는다"와 "신중하지 않아도 상관없다"의 차이를 만듭니다.

설치

uv와 Python 3.13이 필요합니다. 동일한 세 가지 명령이 Windows, macOS, Linux에서 작동합니다:

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

그런 다음 서버가 접근할 수 있는 리포지토리를 지정합니다:

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

...그리고 편집합니다. 파일에는 workspace/repo 항목이 나열되며, 비밀을 포함하지 않고, 커밋하도록 되어 있습니다:

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

전체 워크스페이스는 jantrik/*로 작성할 수 있습니다. 이것은 여기서 가장 넓은 항목입니다 — 작성한 후에 생성된 리포지토리도 포함하므로 — 서버는 모든 시작 시 이를 알려줍니다:

repositories:
  - jantrik/*

서버는 목록 없이는 시작을 거부합니다. 목록이 없으면 자격 증명이 도달할 수 있는 모든 리포지토리에 접근할 수 있는 권한과 구분할 수 없습니다. 전체 워크스페이스보다 좁은 패턴(*/db-explorer, streamstech/db-*)도 같은 이유로 거부됩니다: 그것들은 명명에 대한 추측이며, 그렇게 명명된 모든 것을 포함하게 됩니다.

Bitbucket 계정 연결하기

설정을 실행하고 출력된 링크를 엽니다:

uv run bb-pr-mcp --setup

자신의 머신에서 페이지를 제공합니다 — 루프백 전용, 임의 포트, 일회용 링크, 5분 후 사라짐 — Atlassian 계정 이메일(Bitbucket 사용자 이름도, 토큰에 부여한 이름도 아님)과 API 토큰을 요청합니다. Bitbucket에 대해 쌍을 검증하고 저장하기 전에 표시 이름을 보여준 다음, 자격 증명을 OS 키체인에 넣고 종료합니다.

https://id.atlassian.com/manage-profile/security/api-tokens에서 정확히 다음 네 가지 스코프로 토큰을 생성하세요:

그 이상은 없습니다. 리포지토리에 쓸 수 있거나, 리포지토리를 관리하거나, 파이프라인을 실행할 수 있는 토큰은 양식에서 거부되고 시작 시 다시 거부됩니다.

설정 시 토큰의 만료 날짜를 입력하면 리뷰 중간에 401을 만나는 대신 만료 일주일 전에 경고를 받습니다.

--setup을 명시적으로 실행할 필요는 없습니다: 저장된 자격 증명이 없으면 모든 도구가 오류 대신 설정 URL로 응답합니다.

언제든지 확인할 수 있습니다:

uv run bb-pr-mcp --check

이 명령은 허용 목록, 자격 증명 및 해당 스코프를 검증하고, 누구로 게시 중인지 출력하며, 셸 상태로 종료합니다 — 0 정상, 1 사용 가능한 자격 증명 없음, 2 스코프가 잘못된 토큰.

제거하기

uv run bb-pr-mcp --forget

이 명령은 이 기기의 키체인에서 자격 증명을 삭제할 뿐입니다 — 토큰은 Atlassian에서 직접 해지할 때까지 계속 존재하며, 명령이 이를 알려줍니다. 다음 도구 호출은 새 설정 링크를 제공합니다.

의도적으로 도구가 없습니다. 자격 증명을 삭제하는 도구는 풀 리퀘스트 설명이 모델을 속여 호출하게 할 수 있는 도구이며, 얻을 것도 없습니다: 삭제를 원하는 사람은 이미 터미널에 있습니다.

모델은 토큰을 절대 볼 수 없습니다

토큰은 브라우저에서 키체인으로, 그리고 거기서 Authorization 헤더로 이동합니다. 도구의 인수가 되지 않으며, 도구의 응답에 없고, 오류 메시지에 없으며, 설정 URL에도 없습니다 — 설정 URL에는 다른 일회용 토큰이 포함되며, 이는 이 머신에서 하나의 양식을 작성할 권리만 부여합니다. tests/test_the_token_never_reaches_the_model.py는 이 모든 위치에서 토큰을 찾습니다.

키체인을 사용할 수 없는 경우

자격 증명은 OS 키체인에만 저장되며 다른 곳에는 저장되지 않습니다 — 절대 파일이 아닙니다. macOS와 Windows에서는 기본적으로 작동합니다. Linux에서는 실행 중이고 잠금 해제된 Secret Service(gnome-keyring 또는 KWallet)가 필요합니다. 없으면 서버는 파일로 대체하는 대신 중지합니다 (ADR-0003).

실행하기

서버는 stdio를 통해 MCP를 사용합니다. 클라이언트를 서버에 연결하세요:

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

Windows에서는 Windows 경로("C:\\path\\to\\bitbucket-pr-review-mcp")로 동일한 형태를 사용하세요. 플랫폼 간 다른 점은 없습니다.

Claude Code의 경우:

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

Docker에서 실행하기

이미지는 다른 모든 것과 마찬가지로 stdio를 통해 MCP를 사용하므로 포트도 up할 것도 없습니다. 빌드한 다음 -i로 실행하고 통신하세요.

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

컨테이너에는 키체인이 없으며, 설정 페이지도 도움이 되지 않습니다: 컨테이너 내부의 루프백 포트에 바인딩되므로 브라우저가 접근할 수 없습니다. 따라서 컨테이너 실행은 자격 증명을 저장하는 대신 제공받습니다. 이것은 실제 다운그레이드입니다 — 환경 변수는 docker inspect와 프로세스를 읽을 수 있는 모든 것에 보입니다 — 그리고 대체가 아닌 결정입니다: 아무것도 자동으로 이 방식으로 전환되지 않으며, 두 변수가 모두 설정되어야 하고, 시작 시 매번 이를 알려줍니다. ADR-0007을 참조하세요.

자격 증명을 이 저장소에 없는 파일에 넣으세요:

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

그런 다음 확인하고 클라이언트에 연결하세요:

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은 동일한 플래그를 한 번에 기록합니다: docker compose run --rm bitbucket-pr-review, 이 디렉토리의 .env.docker(gitignored)를 읽습니다.

알아두면 좋은 몇 가지:

• Windows에서는 -v에 Windows 스타일 경로를 사용하세요 (d:/path/to/repositories.yaml:/config/...). Git Bash에서는 MSYS_NO_PATHCONV=1을 명령 앞에 붙이지 않으면 경로가 다시 작성됩니다.

• 허용 목록은 마운트되며, 내장되지 않습니다. 서버가 접근할 수 있는 리포지토리를 지정합니다. 그 목록은 이미지가 아닌 이미지를 실행하는 사람의 것입니다.

• --setup은 컨테이너에서 2로 종료되며, 설정을 실행할 수 있는 위치를 알려줍니다. 토큰을 교체하려면 새 토큰으로 재시작해야 합니다.

• 컨테이너는 비루트 사용자로, 읽기 전용으로, 모든 capability가 제거된 상태로 실행됩니다.

공유 서버에 연결하기

공유 배포 — 여러 사람, 하나의 서버, 각자 자신의 Bitbucket 계정 — 는 단일 오리진 뒤에서 실행됩니다. MCP 엔드포인트와 Keycloak 모두 여기서 제공됩니다. 발급자(issuer)는 토큰, 검색 문서, 브라우저, 구성에서 동일한 의미를 가져야 하는 문자열이기 때문입니다.

Claude Desktop도 Claude Code도 localhost를 통해 서버에 직접 연결하지 않습니다. Claude 사용자 지정 커넥터는 사용자의 머신이 아닌 Anthropic의 인프라에 의해 가져와지므로, 노트북의 서버는 어떻게 구성하든 연결할 수 없습니다. 로컬 루프는 mcp-remote를 통해 진행됩니다: 사용자 머신에서 실행되고, 브라우저에서 OAuth 흐름을 수행하며, 서버에 HTTP로 통신하는 stdio 브리지입니다. 서버에 공개 https 주소가 생기면 사용자 지정 커넥터가 직접 연결할 수 있고 브리지는 더 이상 필요하지 않습니다.

어떤 클라이언트 id를 어디에 사용하는가

realm에는 세 개의 OAuth 클라이언트가 있습니다. 세 가지 다른 것이 인증을 수행하며 서로 교환할 수 없기 때문입니다. 잘못된 것을 사용하면 첫 번째 단계에서 실패하며, Keycloak 오류 페이지에 Invalid parameter: redirect_uri가 표시됩니다 — 이는 클라이언트가 아닌 매개변수를 지목하며, 모든 원인에 대해 동일한 메시지입니다.

구분은 콜백이 도착하는 위치를 따릅니다. 커넥터의 콜백은 https://claude.ai/api/mcp/auth_callback이며 Anthropic의 인프라에 있으므로 해당 클라이언트는 기밀(confidential)이고 시크릿이 거기에 있습니다. 브리지의 콜백은 누군가의 노트북의 루프백 포트이므로 해당 클라이언트는 시크릿을 전혀 보유하지 않습니다 — 노트북의 구성 파일에 있는 시크릿은 시크릿이 아니며, PKCE가 루프백 흐름을 보호합니다. 호스팅된 콜백을 공개 클라이언트에 등록하면 기밀 흐름을 아무것도 지킬 수 없는 클라이언트에 넘기는 것이므로 등록되지 않으며, Keycloak이 거부합니다.

.env.example을 .env로 복사한 다음 시작하세요:

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

이렇게 하면 Postgres, Keycloak, nginx 및 리뷰 서버가 시작됩니다. docker compose --profile shared ps는 네 개의 정상 컨테이너를 표시해야 하며, http://localhost:8080/mcp는 bitbucket:review 스코프를 지정하는 WWW-Authenticate 헤더와 함께 401로 응답해야 합니다 — 인증되지 않은 요청이 거부되는 것이 시스템이 작동한다는 증거입니다.

Claude Code

브리지를 모든 프로젝트에 대해 한 번, -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는 ~/.claude.json의 최상위 mcpServers 키에 작성하며, 모든 디렉토리에 적용됩니다. 대안은 -s local(이 프로젝트만, ~/.claude.json의 projects 아래에도 있음)과 -s project(커밋된 .mcp.json)입니다. 둘 이상의 스코프에 등록하지 마세요: 구성은 분리되어 있고, 사용자 스코프가 우선하며, 나중에 편집하는 것이 사용 중인 것이 아닐 수 있습니다.

확인하세요:

claude mcp get bitbucket-pr-review

Scope: User config와 Status: ✔ Connected를 보고해야 합니다. 세션은 시작할 때 MCP 서버를 인식하므로 이미 실행 중인 Claude Code는 다시 시작할 때까지 새로 등록된 서버를 볼 수 없습니다.

누군가에게 계정 부여하기

realm에는 dev / dev-only-not-for-production 사용자 하나가 포함되어 있으며, 이는 개발용 자격 증명임을 명시합니다. 다른 모든 사람은 로그인하려면 Keycloak에 계정이 필요합니다 — 이는 이후에 /connect에서 스스로 수행하는 Bitbucket 계정 연결과는 별개의 일입니다.

관리 콘솔에서. http://localhost:8080/admin을 열고 부트스트랩 관리자(.env의 KC_BOOTSTRAP_ADMIN_USERNAME / KC_BOOTSTRAP_ADMIN_PASSWORD)로 로그인한 다음, 영역 선택기를 master에서 streamstech로 전환하고 Users → Add user로 이동합니다. 사용자 이름, 이메일, 이름과 성을 입력하고 Email verified를 체크한 후 생성합니다. 그다음 Credentials → Set password에서 Temporary를 끄면 첫 로그인 시 비밀번호 변경을 요구하지 않습니다.

또는 명령줄에서 — 반복하기에는 명령줄이 더 쉽습니다:

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'

Git Bash에서는 각 명령 앞에 MSYS_NO_PATHCONV=1을 붙이지 않으면 /opt/keycloak/...가 Windows 경로로 재작성되어 docker exec가 해당 파일이 존재하지 않는다고 보고합니다.

쉽게 틀리기 쉬운 두 가지가 있는데, 둘 다 생성이 아니라 로그인 시점에 실패하며, 원인을 가리키지 않는 메시지가 표시됩니다:

• 이름과 성은 필수입니다. Keycloak의 사용자 프로필은 이를 필수로 취급하므로, 이 값 없이 생성된 계정은 invalid_grant: Account is not fully set up 오류로 인증에 실패합니다. 계정을 만들 때 어떤 경고도 표시되지 않습니다.

• -t 없이 실행한 kcadm.sh set-password는 이미 영구 설정입니다. -t를 전달하면 임시 설정이 되고 동일한 필수 작업이 대기 상태로 남습니다.

역할이나 그룹 멤버십은 필요 없습니다. 새 계정은 default-roles-streamstech를 자동으로 받으며, 그것으로 충분합니다 — 이 서버는 OAuth 흐름 중에 요청되고 동의되는 bitbucket:review 범위로 인가하며, 사전에 부여하지 않습니다.

계정은 볼륨인 Keycloak 데이터베이스에 저장됩니다. 재시작 후에도 유지되며, docker volume rm bitbucket-pr-review-mcp_keycloak-db를 실행하면 사라집니다.

Claude Desktop

Claude Desktop에는 mcp add 명령이 없습니다. claude_desktop_config.json을 직접 편집해야 합니다. 파일 위치는 Claude 설치 방식에 따라 다릅니다:

Store 경로가 사람들을 자주 혼란스럽게 만듭니다 — Store에서 설치한 경우 %APPDATA% 파일을 완전히 무시하므로, 잘못된 파일을 편집해도 오류 없이 아무 변화가 없습니다.

{
  "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에 동일한 내용이 들어 있습니다. 그중 실제로 작동하는 두 가지 세부 사항이 있습니다:

• Windows에서 npx 앞의 cmd /c. Claude Desktop은 셸을 통해 프로세스를 생성하지 않으므로, "command": "npx"만 쓰면 경로에 공백이 포함된 배치 파일로 해석되어 아래 로그에서 'C:\Program' is not recognized as an internal or external command 오류로 전체가 중단됩니다. macOS에서는 cmd와 /c를 빼고 "command": "npx"를 사용합니다.

• 포트 3334가 아닌 3335. 이 번호는 브리지 자체의 루프백 포트이며, Claude Code의 등록이 이미 3334를 사용합니다. 한 포트에 두 브리지가 있으면 나중에 시작하는 쪽이 OAuth 콜백을 받을 수 없습니다. 영역은 http://127.0.0.1:*/oauth/callback을 등록하므로 사용 가능한 포트는 아무거나 괜찮습니다.

Claude Desktop을 완전히 다시 시작합니다 — 창을 닫아도 실행 중인 상태로 남으므로 트레이에서 완전히 종료해야 합니다 — 그리고 정상 기동을 확인합니다:

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

Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport 줄이 브리지가 서버와 통신 중임을 의미합니다. Server transport closed unexpectedly는 대신 종료되었음을 의미하며, 그 이유는 몇 줄 위에 있습니다.

첫 번째 도구 호출은 Keycloak 로그인 화면을 엽니다(개발 영역의 dev / dev-only-not-for-production 또는 위에서 만든 계정). 로그인 후 도구 호출은 /connect 링크로 응답하며, 여기서 Atlassian 계정을 연결합니다 — 해당 페이지에서 브라우저도 로그인하므로 이 링크는 대화 내용에 표시되어도 안전합니다.

알아두면 좋은 몇 가지:

• 브리지는 공개 OAuth 클라이언트이며 비밀번호가 없습니다. 노트북의 구성 파일에 있는 클라이언트 시크릿은 비밀이 아닙니다. 루프백 흐름을 보호하는 것은 PKCE입니다.

• 콜백은 http://127.0.0.1:3334/oauth/callback입니다 — localhost가 아닌 IP 리터럴이며, Claude Code의 /callback이 아닌 /oauth/callback입니다. 영역은 모두 등록합니다. 잘못 입력하면 흐름의 마지막 단계에서 실패하기 때문입니다.

• 서버가 일반 http로 실행되는 동안 --allow-http가 필요합니다. 실제 배포는 https이며, 이 서버는 루프백 외의 http에서는 자신을 설명하기를 거부합니다.

• 3334 인자는 브리지 자체의 포트이며, 영역은 해당 포트에 콜백을 등록합니다. 두 Claude 클라이언트가 동시에 브리징하려면 서로 다른 포트가 필요합니다.

• **shared 프로필의 기본값은 개발 구성입니다** — 비밀번호가 docker-compose.yaml에 있는 부트스트랩 관리자, 비밀번호가 영역 파일에 있는 사용자를 가진 영역, 루프백의 일반 http. 이 모든 것은 기본값이 있는 변수이므로 실제 배포에서는 두 파일을 편집하는 대신 .env에서 재정의합니다. docs/deploying-the-shared-server.md를 참조하세요.

• 오리진을 변경하려면 영역을 다시 가져와야 합니다. 영역은 Keycloak 데이터베이스에 한 번 가져오며, --import-realm은 기존 영역을 건드리지 않습니다. 해당 볼륨을 이름으로 삭제하세요 — docker volume rm bitbucket-pr-review-mcp_keycloak-db — 그리고 자격 증명 볼트까지 함께 삭제하는 down -v는 절대 사용하지 마세요.

운영

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

--health는 배포가 실행 가능한 상태인지 알려줍니다 — TLS, 볼트 키, 저장소, 허용 목록, 인증 서버 연결 가능 여부, 연결된 사용자 수 — 그리고 정상이면 0, 확인할 사항이 있으면 1, 시작할 수 없으면 2로 종료합니다.

--rotate-key는 누구도 재등록하지 않고 모든 저장된 자격 증명을 새 키로 다시 봉인한 다음, 나머지 작업을 수행할 순서를 알려줍니다.

실제 환경에서 실행하기 전에 docs/deploying-the-shared-server.md를 읽으세요. 호스트가 한 번 침해당했을 때의 비용이 생각보다 크다는 점과 그에 대한 대처 방법이 설명되어 있습니다.

연결된 사용자 확인 및 제거

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

--who는 Bitbucket 계정을 연결한 모든 사용자를 나열합니다: 불투명 ID, Atlassian 이메일, 연결 시각, 토큰 만료 시각. 응답을 위해 볼트를 해독한 다음, 해독할 가치가 있는 한 필드를 제외한 모든 것을 출력합니다.

--revoke는 한 사람의 저장된 자격 증명을 삭제합니다. 이메일 또는 모호하지 않을 만큼 충분한 불투명 ID를 받으며, 이름이 두 사람과 일치하면 추측하지 않고 거부합니다. 해지 효과는 다음 도구 호출부터 적용됩니다, 이미 실행 중인 서버를 포함해서 — 공유 서버는 자격 증명을 보관하지 않고 통과시켜 읽으므로, 다른 터미널의 운영자가 재시작을 기다릴 필요가 없습니다.

이 명령이 하지 않는 일이 읽어볼 가치가 있는 부분입니다. 누군가 떠난 후 세 곳에 무언가가 남아 있으며, 이 명령은 그중 하나만 담당합니다:

• 여기. 저장된 자격 증명이 삭제되었습니다.

• Keycloak. 여전히 로그인하고 새 토큰을 연결할 수 있습니다. 이를 막으려면 해당 계정을 비활성화하세요.

• Atlassian. API 토큰은 여전히 존재하며 다른 모든 곳에서 계속 작동합니다. 본인 또는 Atlassian 관리자만 해지할 수 있습니다.

이 명령은 매번 세 가지를 모두 언급합니다. 1단계 후에 체크되는 퇴사 체크리스트는 체크리스트가 없는 것보다 나쁘기 때문입니다.

둘 다 도구가 아니며, 이는 의도적입니다: 풀 리퀘스트 설명이 Caller를 설득해 동료의 연결을 끊게 해서는 안 됩니다.

도구

풀 리퀘스트는 하나의 문자열로 지정합니다: Bitbucket URL 또는 약식 workspace/repo/id.

구성

아래 모든 항목에는 작동하는 기본값이 있습니다. 환경 변수 또는 .env 파일에 설정하며, 모두 BB_MCP_ 접두사를 사용합니다:

두 가지가 더 있으며 공유 배포가 완료될 때까지 비어 있습니다 — 위에서 설명한 장치별 설치에는 둘 다 필요하지 않습니다. stdio에는 호출자가 정확히 하나뿐이기 때문입니다:

모든 한도는 적용될 때 응답에 명시됩니다. 잘림은 결코 조용히 일어나지 않습니다. 잘린 diff와 완전한 diff를 구분할 수 없는 호출자는 누락된 절반이 문제없었다고 가정하고 검토할 것입니다.

개발

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

테스트는 절대 네트워크에 접근하지 않습니다. 경계면은 HTTP 전송 계층뿐이므로, 가드, 허용 목록, 모든 응답 리더가 프로덕션 코드로 실행됩니다. tests/recorded/에는 실제 풀 리퀘스트에서 캡처한 응답이 들어 있습니다 — 이것이 왜 들리는 것보다 더 중요한지에 대해서는 docs/architecture.md를 참조하세요.