BetaDrop MCP

Referência do servidor MCP

@betadrop/mcp expõe o BetaDrop a qualquer cliente que fale o Model Context Protocol (Claude Code, Claude Desktop, Cursor, VS Code com Copilot) como vinte e três ferramentas que um assistente pode chamar. Ele roda localmente via stdio e usa as mesmas credenciais da CLI. A visão geral do MCP cobre a configuração por editor em mais detalhes; esta página é a superfície de ferramentas.

Configurar um cliente

Não há nada para instalar antecipadamente. npx busca o pacote na primeira execução. Node 18 ou mais recente é o único requisito. No Claude Code, um comando o registra para todos os projetos:

claude mcp add betadrop -s user -- npx -y @betadrop/mcp

Todos os outros clientes são o mesmo servidor descrito no arquivo de configuração desse cliente. Claude Desktop e Cursor usam um objeto mcpServers; VS Code usa servers com uma entrada idêntica em todos os outros aspectos:

{
  "mcpServers": {
    "betadrop": {
      "command": "npx",
      "args": ["-y", "@betadrop/mcp"]
    }
  }
}

Reinicie ou atualize o cliente depois; os servidores MCP são descobertos na inicialização.

Autenticação

O servidor resolve as credenciais exatamente da mesma forma que a CLI, o que lhe dá três opções em ordem decrescente de quanto você deve gostar delas.

• Já conectado com a CLI. Nada a fazer. Ambos leem o mesmo arquivo de credenciais, então uma máquina onde betadrop login foi executado já está autenticada aqui. Esta é a opção sem segredo em nenhum arquivo de configuração.
• Peça ao assistente para entrar. Chame betadrop_login com um token. Ele valida o token contra o servidor antes de salvar e grava na mesma configuração compartilhada. Fazer isso uma vez também conecta a CLI.
• Uma variável de ambiente na configuração. BETADROP_TOKEN é lida do ambiente do servidor e tem precedência sobre a credencial armazenada. Funciona, mas significa um token em texto puro em um arquivo de configuração do editor — vale evitar, a menos que as outras duas sejam impossíveis.

Token na configuração do cliente (último recurso)

{
  "mcpServers": {
    "betadrop": {
      "command": "npx",
      "args": ["-y", "@betadrop/mcp"],
      "env": { "BETADROP_TOKEN": "bd_live_xxxxxxxx" }
    }
  }
}

Os tokens vêm de Configurações → Desenvolvedor → Tokens de API no painel, ou de betadrop_token_create abaixo. De qualquer forma, o valor em texto puro é mostrado exatamente uma vez.

Ferramentas

Vinte e três ferramentas. Os argumentos obrigatórios estão marcados; todo o resto é opcional. Você não chama essas ferramentas pelo nome na prática. Você pede ao assistente o resultado e ele escolhe. Saber o que existe é o que impede você de pedir algo que não existe.

Ferramenta	Argumentos	O que faz
betadrop_whoami	Nenhum	Relata o status de autenticação, a conta ativa e o servidor com o qual está falando.
betadrop_login	token (obrigatório), apiUrl	Valida um token de API contra o servidor e o salva no arquivo de credenciais compartilhado da CLI.
betadrop_logout	Nenhum	Revoga o token ativo no servidor e limpa as credenciais locais.
betadrop_publish	filePath (obrigatório), name, version, buildNumber, bundleId, notes, expiryType, expiryTimeDays, expiryDownloadLimit, expiryDeviceLimit, standingLink	Publica um .ipa ou .apk. filePath deve ser absoluto. standingLink aponta um link permanente para o build assim que ele estiver no ar (0.3.0+). Veja a nota de expiração abaixo.
betadrop_upload_status	Nenhum	Busca o resultado — incluindo o link de instalação — do betadrop_publish mais recente. Um upload que ultrapassa a janela de publicação de 90 segundos continua rodando em segundo plano, e é assim que o assistente conclui o trabalho; chame apenas quando betadrop_publish relatou que o upload ainda estava em execução.
betadrop_list_builds	platform, status, page, perPage	Lista builds recentes. platform é ios ou android; status é um de active, expired, disabled, deprecated ou latest. A paginação padrão é de 20 por página, máximo 100.
betadrop_list_expired_builds	platform, page, perPage	Apenas builds expirados, com o motivo da expiração. Um atalho para a ferramenta anterior com status: expired.
betadrop_token_list	Nenhum	Lista os tokens de API ativos da conta.
betadrop_token_create	name (obrigatório), abilities, expiresInDays	Cria um token. abilities é qualquer um de publish, read ou * e o padrão é *; expiresInDays é 1–365, e omiti-lo significa sem expiração. O valor em texto puro é retornado uma vez.
betadrop_token_delete	tokenId (obrigatório)	Revoga um token pelo seu id, conforme listado por betadrop_token_list.
betadrop_inspect	filePath (obrigatório)	O build será instalado a partir de um link? Relata o tipo de perfil e expiração, correspondência do bundle ID, assinatura e testOnly / debuggable, com um veredito. Nada é publicado. 0.3.0+.
betadrop_list_standing_links	Nenhum	Links permanentes, o build que cada um serve e quantos testadores seguem cada um. 0.3.0+.
betadrop_point_standing_link	slug, buildId (ambos obrigatórios)	Aponta um link permanente para um build enviado; os seguidores são notificados por e-mail. 0.3.0+.
betadrop_delete_build	buildId (obrigatório)	Exclui um build. O link de instalação dele para de funcionar. 0.3.0+.
betadrop_get_feedback	buildId (obrigatório)	Feedback que os testadores deixaram em um build. 0.3.0+.
betadrop_list_devices	Nenhum	Dispositivos iOS registrados (UDIDs). 0.3.0+.
betadrop_export_devices	Nenhum	Os dispositivos como o arquivo separado por tabulações que o portal da Apple e o fastlane register_devices aceitam. 0.3.0+.
betadrop_invite_device	name, email, open	Um link de registro de UDID: enviado por e-mail a um testador com name e email, ou o compartilhável com open: true. 0.3.0+.
betadrop_list_webhooks	Nenhum	Webhooks na conta. 0.3.0+.
betadrop_create_webhook	url (obrigatório), events, format	Envia eventos de build para uma URL; URLs do Slack e do Discord são detectadas. Retorna o segredo de assinatura uma vez. 0.3.0+.
betadrop_test_webhook	webhookId (obrigatório)	Entrega um evento de teste agora e relata a resposta do receptor. 0.3.0+.
betadrop_delete_webhook	webhookId (obrigatório)	Remove um webhook. 0.3.0+.
betadrop_help	Nenhum	Uma referência rápida integrada: a lista de ferramentas, suas entradas e exemplos de prompts. Útil quando o assistente precisa ser lembrado do que pode fazer.

Argumentos de expiração na publicação

betadrop_publish é a única ferramenta que pode definir a expiração de um build no momento do upload, e seus quatro argumentos de expiração funcionam juntos, não de forma independente. expiryType escolhe a estratégia e os argumentos numéricos fornecem o limite que essa estratégia precisa.

expiryType	Exige
none	Nada. O build não expira por conta própria.
time	expiryTimeDays. Expira após N dias.
downloads	expiryDownloadLimit. Expira após N downloads.
devices	expiryDeviceLimit. Expira após N dispositivos únicos.
combined	Qualquer combinação dos três limites numéricos. O que for atingido primeiro encerra o build.

O teto de retenção do seu plano ainda se aplica. Esses argumentos escolhem uma vida mais curta que o máximo, nunca mais longa. A CLI aceita os mesmos limites como flags publish (--expires-in-days, --max-downloads, --max-devices, 0.4.0+).

Notas

• Caminhos absolutos. betadrop_publish aceita um filePath absoluto. Um servidor MCP não compartilha necessariamente um diretório de trabalho com o seu editor, então um caminho relativo é ambíguo em vez de conveniente.
• Mesma validação da CLI. A extensão deve ser .ipa ou .apk e o arquivo deve ser realmente um arquivo ZIP — ambos são verificados localmente antes de qualquer upload.
• Ele roda na sua máquina. O servidor é um processo local que fala stdio com o seu cliente. O arquivo de build nunca passa pelo assistente; ele é lido do disco e enviado diretamente.
• As ferramentas de token são reais. betadrop_token_create e betadrop_token_delete criam e revogam credenciais ativas. Isso é conveniente e também é um motivo para ler o que um assistente propõe antes de aprovar.