Let your coding agent ship the build
Your AI assistant already has the code and can already run the build. The one thing it cannot do is get the result onto someone's phone. BetaDrop's MCP server is that missing step — the agent publishes the .ipa or .apk and hands you back an install link, without you opening a dashboard or editing a CI config.
Works in Claude Code, Claude Desktop, Cursor and VS Code with Copilot.
What it looks like
You type
“Build the Android app and give me a link I can send to the team.”
- The agent runs your existing build command.
- It calls
betadrop_publishwith the resulting artifact. - BetaDrop screens the build, stores it, and mints an install page.
- The agent replies with the install URL. You paste it into Slack; your tester opens it on a phone and installs.
No part of that is new capability on our side — it is the same upload path the CLI and the GitHub Action use. What is new is that nobody had to decide in advance that this particular build was worth publishing.
What the agent is given
Eleven tools. Most sessions only ever touch the first one.
Publishing
betadrop_publish · betadrop_upload_status
Uploads the build and returns the install URL. This is the one that matters.
Looking things up
betadrop_list_builds · betadrop_list_expired_builds
So the agent can answer “what did we ship last week” without you opening the dashboard.
Credentials
betadrop_token_create · betadrop_token_list · betadrop_token_delete
Including deletion, which is what makes issuing a throwaway token for an agent practical.
Session
betadrop_login · betadrop_logout · betadrop_whoami · betadrop_help
betadrop_whoami is worth knowing: it tells you which account the agent is actually acting as.
Setup — the config block for each client — is on the MCP page. The server is published as @betadrop/mcp and listed in the MCP Registry as io.github.betadrop-app/betadrop-mcp.
Before you hand an agent a publish token
A BetaDrop token uploads builds under your account. An agent that can publish can publish something you did not intend to publish — a debug build, a branch, a binary with a test endpoint baked in. That is worth a moment's thought before you paste a token into a config file.
The practical shape: issue a token for the agent, keep it out of your repository, and delete it when that setup is done. Both creating and deleting live in Settings → Developer → API tokens, and the agent can do them itself. If that trade is not one you want to make, do not make it — the CLI and the GitHub Action reach the same destination with the credential under CI's control instead.
What an agent still cannot do
It cannot conjure a signing identity. An iOS build still has to be signed with a provisioning profile covering the device it will install on, which means your certificates and your Apple Developer account — and, for a device not already in the profile, a round trip to Apple. An agent with your keychain and a configured Xcode project can drive that; an agent starting from nothing cannot.
Android has no equivalent gate, which is why the agent workflow feels effortless there and fiddly on iOS. That asymmetry is Apple's, not ours — the detail is on IPA signing.
This does not replace CI
CI publishes on a rule you wrote in advance — every push to main, every pull request. An agent publishes because you asked it to, mid-task, without opening a config file. Most teams want both, and they do not conflict: builds that should always ship belong in a pipeline, and the build you want in your hand right now belongs in a sentence. Links from either route expire the same way — 3 days by default — which is what keeps a conversational workflow from quietly becoming a storage problem.
Frequently Asked Questions
What is AI app distribution?
Distributing a mobile build through an AI coding assistant instead of through a dashboard or a CI config. The assistant already has your code and can already run your build; an MCP server gives it the one capability it lacks — publishing the resulting .ipa or .apk and getting back a shareable install link. In practice you type "build this and give me a link I can send to the team" and the agent does the whole sequence.
Which AI assistants can publish to BetaDrop?
Any client that speaks the Model Context Protocol. The four documented setups are Claude Code, Claude Desktop, Cursor, and VS Code with Copilot. The server runs as `npx -y @betadrop/mcp` with a BETADROP_TOKEN in the environment, so a client not on that list works too if it can launch a stdio MCP server.
What can the agent actually do?
Eleven tools: publish a build, list builds, list expired builds, check upload status, create, list and delete API tokens, log in, log out, check who it is authenticated as, and fetch its own help. The one that matters is publish — it returns the install URL, which is what the agent hands back to you.
Can an AI agent build and sign an iOS app by itself?
It can build one. It cannot conjure a signing identity. An over-the-air install still needs a build signed with a provisioning profile covering the installing device, which means your certificates, your Apple Developer account, and — for a device not already in the profile — a round trip to Apple. An agent with access to your keychain and a configured Xcode project can drive that; an agent starting from nothing cannot. Android has no equivalent gate: a signed .apk installs from a browser.
Is it safe to give an AI agent a publish token?
It is a real credential and worth treating as one. A publish token can upload builds under your account, and an agent that can publish can publish something you did not intend. Tokens can be created and deleted from Settings → Developer → API tokens, and the MCP server exposes both operations, so the practical answer is to issue a token for the agent, keep it out of your repository, and delete it when you are done with that setup. If you are not comfortable with that, the CLI and the GitHub Action do the same job with the credential under CI's control instead.
Does the agent need my account, or can it work anonymously?
It needs a token, so it needs an account. The anonymous path — one guest upload with a link that expires after 24 hours — is a browser flow, not an API one, and exists so a person can prove the product works before signing up. An agent publishing repeatedly is exactly the case an account is for.
How is this different from using the CLI or the GitHub Action?
The mechanism is the same and the destination is identical; what differs is who decides to publish. CI publishes on a rule you wrote in advance — every push to main, every pull request. An agent publishes because you asked it to, in the middle of doing something else, without you opening a config file. Most teams end up with both: CI for the builds that should always ship, an agent for the build you want right now.
What happens to all the builds an agent publishes?
The same thing that happens to any other build: a link lives 3 days by default and the file is deleted when it expires rather than archived. That default suits agent-driven publishing well, because the failure mode of a conversational workflow is publishing more builds than you would by hand, and a link that cleans itself up is what stops that becoming a storage problem.
Give your agent somewhere to ship to
Two steps: add the MCP server to your client, give it a token.
Part of: CI/CD Beta App Distribution
