MCP server reference

@betadrop/mcp exposes BetaDrop to any client that speaks the Model Context Protocol — Claude Code, Claude Desktop, Cursor, VS Code with Copilot — as ten tools an assistant can call. It runs locally over stdio and uses the same credentials as the CLI. The MCP overview covers per-editor setup in more detail; this page is the tool surface.

Configure a client

There is nothing to install ahead of time — npx fetches the package on first run. Node 18 or newer is the only requirement. In Claude Code, one command registers it for every project:

Claude Code

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

Every other client is the same server described in that client's config file. Claude Desktop and Cursor use an mcpServers object; VS Code uses servers with an otherwise identical entry:

claude_desktop_config.json / .cursor/mcp.json

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

Restart or refresh the client afterwards; MCP servers are discovered at startup.

Authentication

The server resolves credentials exactly the way the CLI does, which gives you three options in decreasing order of how much you should like them.

Already logged in with the CLI. Nothing to do. Both read the same credentials file, so a machine where betadrop login has been run is already authenticated here. This is the option with no secret in a config file anywhere.
Ask the assistant to log in. Call betadrop_login with a token. It validates the token against the server before saving, and it writes to the same shared config — so doing this once also logs the CLI in.
An environment variable in the config. BETADROP_TOKEN is read from the server's environment and takes precedence over the stored credential. It works, but it means a plaintext token sitting in an editor config file — worth avoiding unless the other two are impossible.

Token in the client config — the last resort

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

Tokens come from Settings → Developer → API tokens in the dashboard, or from betadrop_token_create below. Either way the plaintext value is shown exactly once.

Tools

Ten tools. Required arguments are marked; everything else is optional. You do not call these by name in practice — you ask the assistant for the outcome and it picks — but knowing what exists is what stops you asking for something that does not.

Tools exposed by the BetaDrop MCP server
Tool	Arguments	What it does
betadrop_whoami	None	Report authentication status, the active account and the server it is talking to.
betadrop_login	`token` (required), `apiUrl`	Validate an API token against the server and save it to the shared CLI credentials file.
betadrop_logout	None	Revoke the active token server-side and clear the local credentials.
betadrop_publish	`filePath` (required), `name`, `version`, `buildNumber`, `bundleId`, `notes`, `expiryType`, `expiryTimeDays`, `expiryDownloadLimit`, `expiryDeviceLimit`	Publish an `.ipa` or `.apk`. `filePath` must be absolute. See the expiry note below.
betadrop_list_builds	`platform`, `status`, `page`, `perPage`	List recent builds. `platform` is `ios` or `android`; `status` is one of `active`, `expired`, `disabled`, `deprecated` or `latest`. Paging defaults to 20 per page, maximum 100.
betadrop_list_expired_builds	`platform`, `page`, `perPage`	Expired builds only, with the expiry reason. A shortcut for the previous tool with `status: expired`.
betadrop_token_list	None	List the account's active API tokens.
betadrop_token_create	`name` (required), `abilities`, `expiresInDays`	Create a token. `abilities` is any of `publish`, `read` or `` and defaults to ``; `expiresInDays` is 1–365, and omitting it means no expiry. The plaintext value is returned once.
betadrop_token_delete	`tokenId` (required)	Revoke a token by its id, as listed by `betadrop_token_list`.
betadrop_help	None	A built-in quick reference: the tool list, their inputs, and example prompts. Useful when the assistant needs reminding what it can do.

Expiry arguments on publish

betadrop_publish is the one tool that can set a build's expiry at upload time, and its four expiry arguments work together rather than independently. expiryType chooses the strategy and the numeric arguments supply the threshold that strategy needs.

Values accepted by the expiryType argument
expiryType	Requires
none	Nothing. The build does not expire on its own schedule.
time	`expiryTimeDays` — expire after N days.
downloads	`expiryDownloadLimit` — expire after N downloads.
devices	`expiryDeviceLimit` — expire after N unique devices.
combined	Any combination of the three numeric limits. Whichever is reached first ends the build.

Your plan's retention ceiling still applies — these arguments choose a shorter life than the maximum, never a longer one. Device and download limits are the reason this tool is worth using over the CLI for a sensitive build: neither has an equivalent publish flag.

Notes

Absolute paths. betadrop_publish takes an absolute filePath. An MCP server does not necessarily share a working directory with your editor, so a relative path is ambiguous rather than convenient.
Same validation as the CLI. The extension must be .ipa or .apk and the file must really be a ZIP archive — both are checked locally before anything is uploaded.
It runs on your machine. The server is a local process speaking stdio to your client. The build file never passes through the assistant; it is read from disk and uploaded directly.
Token tools are real. betadrop_token_create and betadrop_token_delete mint and revoke live credentials. That is convenient and it is also a reason to read what an assistant proposes before approving it.