The API-group filter is the practical detail: this server has a lot of tools, and a client with a tool-count limit can enable just apps and builds. OAuth means most modern clients sign in once with no token handling, and the release-management group is worth enabling on its own to avoid confusing it with the apps group, as the docs recommend.
Bitrise's own MCP server over the Bitrise API, covering app setup, build operations, artifacts, webhooks and release management, grouped into API groups you can enable selectively.
- Apps — list_apps, register_app, get_app, get_bitrise_yml and update_bitrise_yml, plus list_branches
- Builds — trigger_bitrise_build, get_build, abort_build, get_build_log and list_build_workflows
- Artifacts — list_artifacts, get_artifact and delete_artifact
- Webhooks — create_outgoing_webhook, list_outgoing_webhooks and their update/delete counterparts
- Pipelines, cache items, workspaces, group roles and account tools
- Release management — connected apps, installable artifacts, tester groups and CodePush deployments
- Tool exposure limited by API group, via ENABLED_API_GROUPS locally or the x-bitrise-enabled-api-groups header remotely
OAuth authentication — sign in once with your Bitrise account, no token to copy for clients that speak MCP OAuth. Clients that do not can pass a Bitrise Personal Access Token in the Authorization header. A hosted remote server runs at https://mcp.bitrise.io/ over streamable HTTP.
One command — claude mcp add --transport http bitrise https://mcp.bitrise.io