FidelisMM/shipstores

60 tools ·
Workflows ·
Hard-won lessons ·
Contributing
---
**shipstores** drives App Store Connect and Google Play Console end to end — builds, store listings, screenshots, privacy labels, review submission and even replying to App Review — so Claude (or any MCP client) can take an app from eas build to "Waiting for Review" without you clicking through two consoles.
> Built because publishing was always the slowest part of shipping an app. Every quirk documented below cost at least one rejected build to discover.
Why
Publishing a mobile app is ~40 manual steps across two consoles, half of which have no public API. AI agents can write your app, but they stall at the store. This server closes that gap:
| | App Store Connect | Google Play |
|---|---|---|
| Upload build, versions, listing, screenshots | ✅ API | ✅ API |
| Subscriptions / in-app purchases | ✅ API | — |
| Age rating, categories, price, URLs | ✅ API | ✅ API |
| **Privacy label & country availability** | ✅ console's internal API | ✅ Data safety via console |
| **Read the rejection & reply to App Review (with video)** | ✅ console | — |
| **"App content" declarations** (11 forms, no API) | — | ✅ console automation |
| Create the app record | 🧭 opens the right form, tells you what to type | 🧭 same |
| Expo / EAS builds | ✅ start, poll, download, submit | ✅ |
Neither store lets anyone create an app record through an API, so *_create_app_form opens the right page in a logged-in browser and returns the exact values to fill. Everything else is automated.
How it compares
There are other good MCP servers for the stores, such as app-publish-mcp and mobile-release-mcp, and they cover the public APIs well. shipstores focuses on the steps that have no public API and usually end up done by hand: replying to App Review, the App Store privacy label and Google Play's "App content" declarations. It also keeps the tool list short (60 tools), and tools that publish or submit say so in their description, so the agent asks before acting.
If you only need what the public APIs offer, any of them will do. If you keep getting stuck on the console-only steps, that's the gap this project fills.
Quick start
Requirements: Python 3.12+, uv, an App Store Connect API key and/or a Google Play service account. Xcode command line tools for iOS uploads (xcrun altool).
Add it to Claude Code (no clone needed, uvx fetches it from PyPI and runs it):
Then ask your agent: *"run store_doctor"*. It checks both credentials with real calls and detects your Apple Team ID for you.
Credentials
| Variable | Required | What it is |
|---|---|---|
| ASC_KEY_ID, ASC_ISSUER_ID | iOS | App Store Connect → Users and Access → Integrations → API key (role **Admin** or **App Manager**) |
| ASC_PRIVATE_KEY_PATH | iOS | the .p8 file (default ~/.config/shipstores/AuthKey_ .p8) |
| APPLE_TEAM_ID | no | detected by store_doctor from any bundle ID |
| PLAY_SERVICE_ACCOUNT_PATH | Android | service account JSON invited in Play Console with release permissions |
| PLAY_DEVELOPER_ID | console forms | the number after /developers/ in the Play Console URL |
| SHIPSTORES_TOOLSETS | no | comma-separated tool groups to expose: apple, play, and/or eas; core diagnostics are always enabled (default: all groups) |
For example, SHIPSTORES_TOOLSETS=apple,eas exposes only Apple and EAS tools, plus core diagnostics. The same setting can be configured as [server] toolsets = ["apple", "eas"] in ~/.config/shipstores/config.toml. Values can also live in that file — see config.example.toml. Nothing secret is ever written to the repo.
Console features (optional)
Privacy labels, availability, App Review replies and Play "App content" forms run through the store consoles' own web endpoints in a dedicated, logged-in browser profile, driven by browser-harness. Log in once: