appstore-release-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPLE_KEY_ID | Yes | ASC API key ID | |
| ASC_KEY_PATH | No | Path to the .p8 file (alternative to APPLE_KEY_CONTENT) | |
| ASC_PLATFORM | No | Platform: IOS (default), MAC_OS, TV_OS, VISION_OS | IOS |
| APPLE_TEAM_ID | No | Apple Developer team ID (required for builds) | |
| ASC_BUNDLE_ID | Yes | Your app's bundle identifier | |
| ASC_UPLOAD_CMD | No | Full override command for upload, e.g. bundle exec fastlane ios beta | |
| APPLE_ISSUER_ID | Yes | ASC issuer ID | |
| ASC_PROJECT_DIR | No | Xcode project root where fastlane runs (default: current working directory) | |
| APPLE_KEY_CONTENT | No | Base64-encoded .p8 file content (alternative to ASC_KEY_PATH) | |
| ASC_FASTLANE_LANE | No | Upload lane name (default: beta) | beta |
| ASC_FASTLANE_PLATFORM | No | Fastlane platform prefix, e.g. mac or ios |
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 |
|---|---|
| asc_doctorA | Verify the release toolchain end-to-end: ASC API credentials, mac-app directory, fastlane, xcodebuild, and (if creds are present) that the app record exists in App Store Connect. Run this first in any release session. |
| asc_app_statusA | Snapshot of the app's release state: latest App Store versions with their review states, and recent builds with processing states. Use this to answer 'where is the release right now?' |
| asc_list_buildsA | List recent uploaded builds and their processing states (PROCESSING → VALID before they can be submitted). Use after an upload to watch for the build becoming VALID. |
| asc_bump_versionA | Bump the local app version before a build. Increments the build number (CURRENT_PROJECT_VERSION) and optionally sets a new marketing version. Updates every .xcodeproj/project.pbxproj in the project dir, plus project.yml if the project uses xcodegen, so all sources stay in sync. |
| asc_upload_buildA | Archive, sign, and upload the app to TestFlight via the configured fastlane lane (default: |
| asc_job_statusA | Check a build/upload job started by asc_upload_build. Returns status (running/succeeded/failed) and the tail of the log. |
| asc_update_metadataA | Update App Store listing metadata (description, keywords, what's-new, promotional text) on the currently editable version via the ASC API. If no editable version exists, pass create_version to open a new one. |
| asc_submit_reviewA | Submit the editable App Store version for review: optionally attach a build, then create and submit a review submission. The build must have processingState VALID (check asc_list_builds). This is the point of no return for a release — confirm with the human first. |
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 8 tools
Each tool addresses a distinct step in the release workflow (environment check, version bump, upload, status polling, build listing, metadata update, submission). No two tools have overlapping responsibilities.
All tools share the 'asc_' prefix and use lowercase with underscores. Most are verb_noun (bump_version, list_builds), but 'asc_doctor' and 'asc_app_status' are noun-based, introducing slight inconsistency.
With 8 tools, the set is well-scoped for a release management server. Each tool serves a necessary function without redundancy, and the number is ideal for agent usability.
The tools cover the essential release lifecycle: environment verification, version bumping, build upload, status tracking, build listing, metadata update, and review submission. Minor gaps like cancellation or rollback are not present but are acceptable for a focused toolset.