@appdropper/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPDROPPER_TOKEN | No | API token; overrides the saved login. The server looks for a token in this order: APPDROPPER_TOKEN in the server's environment, then the saved login from `npx appdropper login`. | |
| APPDROPPER_API_URL | No | API base URL | https://appdropper.io/api/v1 |
| APPDROPPER_MCP_TIMEOUT | No | Seconds `upload_build` waits for App Dropper to process a build | 600 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| upload_buildA | Upload a local Android .apk or iOS .ipa to App Dropper, wait for it to be processed, and return the app name, version, build number and the tester install URL. Use when the user asks to upload, share, send or distribute a mobile build to testers. Side effects: sends the file to App Dropper, publishes it as the newest build of its app (matched by bundle ID; a new bundle ID creates a new app when the token allows it), and notifies that app's testers by email and push. Takes from a few seconds to several minutes for large builds. If the path is unknown, call find_builds first. Does not build, sign or re-sign the app. |
| find_buildsA | Search a project directory for Android .apk and iOS .ipa build artifacts, newest first, with size, modification time, platform and release/debug variant. Read-only: nothing is uploaded. Use when the user wants to upload 'the latest build' and you don't know the output path. Skips dependency and hidden folders (node_modules, Pods, .git, .dart_tool, .gradle…) and never follows symlinks. |
| list_appsA | List the App Dropper apps the configured token can upload to, with their app IDs, bundle IDs and public install pages. Use to answer which apps are available, or to get an app_id for list_builds. Read-only. |
| list_buildsA | List an App Dropper app's most recent builds, newest first, with version, build number, platform, upload date, status and install URL. Use for questions like 'what were the last builds I sent' or to find a previous install link. Read-only. |
| get_buildA | Get one App Dropper build by its build_id: app, version, build number, platform, release notes, upload and expiry dates, install count, install URL and QR code URL. Read-only. |
| whoamiA | Check whether this MCP server is signed in to App Dropper and show the credential's name, where it was found, its expiry and which apps it covers. Never reveals the token. Use to debug setup or when another App Dropper tool reports an authentication problem. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct resource and action: find_builds searches local files, list_apps lists remote apps, list_builds lists remote builds, get_build retrieves a single build, upload_build writes, and whoami checks auth. The similar names find_builds and list_builds are clearly differentiated by their descriptions (local directory search vs. remote app builds), leaving no real ambiguity.
All names use snake_case and follow a verb_noun pattern (upload_build, find_builds, list_apps, list_builds, get_build). The only deviation is whoami, which is a single word rather than verb_noun, but it is a standard, readable convention.
Six tools is well-scoped for a build distribution service. Each tool has a clear purpose (upload, local discovery, app listing, build listing, single build retrieval, auth) and none appear redundant.
Core build distribution workflows are covered: find local build, upload, list apps, list builds, get build details, and verify auth. Missing operations like deleting a build or updating release notes are minor gaps that agents can work around, but they slightly limit full lifecycle coverage.