What to ask
You talk to your agent in plain words: say the outcome, and it picks Ploa's tools in the right order. For the bigger jobs, Ploa's MCP server also gives it briefs, step-by-step instructions it follows so the work comes out the same way each time.
To start
Ship this app to the App Store and Google Play with Ploa.
The agent runs ploa_setup_guide and first asks how it should work: on its own, or asking you before each review, release and price change (Choosing at the start). Then it shows you the stages board, links the folder to Ploa, and sends you one numbered message with everything that's yours for both stores: the questions only you answer (the app's ID, the store page's languages, countries, price, who it's for, the contacts) and your steps in the consoles, each with its link. While you do those, it writes the store page, makes the screenshots and checks the build.
The briefs
MCP calls them prompts. In Claude Code they're slash commands: type / and look for ploa (for example /mcp__ploa__fill_store_page). In other agents they're in the prompts or commands menu. Or just ask for the job, and the agent follows the brief by itself. Arguments are optional; when one is left out, the agent asks or picks the usual choice.
The briefs read your app's code, so they're for an agent with the server on your computer. On the web, set_up_app, make_screenshots and answer_privacy lack the tools they rely on.
set_up_app
From an app with no store setup to its first builds on TestFlight and Google Play internal testing. The agent asks how it should work, shows the stages board after every step, offers app IDs and sets the one you pick in the project, does its own steps (linking the folder, registering the bundle ID at Apple), and sends your questions and your steps for both stores in one message. Meanwhile it writes the store details and privacy answers as drafts, makes the screenshots, hosts a privacy policy and support page on the app's web on Ploa if the app has none, and checks the iOS build on a Mac without sending it. Once a store is ready it runs preflight and starts that store's first build. No arguments.
fill_store_page
The whole store page for both stores from the app's own code: it asks what only you decide first (languages, countries, price, who it's for, App Review's contact and the store page's public contact, asked apart), reads the app, then writes every text field within each store's limits, the screenshots and the privacy answers, the category, age rating, price and review details, all saved as drafts for you to send. Arguments: language (one language, in either store's code), store (apple, google or both, the default).
translate_store_page
The store page in more languages: each store's own language code (Hebrew is he at Apple and iw-IL at Google), text written for that market rather than word for word, App Store keywords found again for each language, and the app's own translations reused so the page matches its screens. Arguments: languages (separated by commas; when left out, the agent suggests some and asks), from (the language to translate from; the most complete one by default), store.
make_screenshots
The screenshots each store requires, at the exact sizes, from the app running in a simulator or emulator: 4 to 8 screens that tell the app's story, a clean status bar, each file checked, then uploaded in order once you agree (straight to the store, not a draft). An App Store app preview or a Google Play promo video only if you want one. Arguments: store, language.
answer_privacy
What data the app collects and why, worked out from its packages, permissions and code (network calls, analytics, sign-in, crash reports, ads, payments), saved once for Apple's App Privacy and Google Play's Data safety. It asks you what the code can't show, then says what to enter in each console, where you mark it done. Argument: store.
handle_rejection
Why App Review or Google Play rejected the app: the store's message (pasted by you, since the stores' APIs don't give the reviewer's words), the guideline, the cause in the code, the store page or the review details, the fix, a new build if the code changed, and a new submission for you to approve. A reply to App Review is drafted only when its message asks for one. Arguments: store, message (the store's message, pasted).
write_release_notes
"What's New" for the next version from what changed since the last release (the pull requests merged since, when the repository is linked to Ploa, else the git log), in every language the store page has, saved in the store details: for the App Store's version being prepared, and for the next build Ploa puts on Google Play (or a build that went out without notes, when Ploa promotes it). One text for both stores, or each store's own where one would name the other platform (App Store notes never name Android or Google, Google Play notes never Apple, iPhone or Mac). Arguments: since (a git tag or commit; the last released version by default), language, store.
Every brief ends the same way: the agent saves drafts and you send them, unless it's autonomous.
Requests that work well, stage by stage
In the order an app goes through them. Each stage links to its tools in Every MCP tool.
Start and setup
Where are we with the stores? Show me the stages board and what's mine.
Which Ploa account and access do you have?
Register the bundle ID at Apple and link this folder to Ploa.
Tools: Start and setup.
Steps only you can do
What's waiting for me in the store consoles? Walk me through it step by step.
Tools: Steps only you can do.
Store details
Write the store page from the code in English, then translate it to Hebrew and Spanish.
What would each store still refuse on the store page?
Set the age rating and the category, and fill App Review's contact and notes.
Tools: Store details.
Privacy and export compliance
Work out the privacy answers from the code and tell me what to enter in App Store Connect and Play Console.
Does the app use encryption that Apple needs declared? Ask me what you can't tell from the code.
Tools: Privacy, Export compliance.
Screenshots and videos
Make the screenshots from the simulator and show them to me before uploading.
Put the screenshots in this order: home, search, profile.
Tools: Screenshots and videos.
Builds
Run preflight, fix what it finds, and send version 1.3 to TestFlight and internal testing.
Build the Android app on GitHub from what's on main.
Stop the Android build that's running: it's on the wrong branch.
Tools: Builds.
Testers
Add these three people as TestFlight testers and write what to test in this build.
Who tests the Android app now, and on which track?
Tools: Testers.
App Review and production
Submit the build for App Review once it's on TestFlight.
Where is the version with App Review, and what's next?
Promote the Android release to production at 20%, and check crash rates first.
Release the approved version on the App Store as a phased release.
Tools: App Review and production.
Rejections
Why was the app rejected? Fix it and prepare a new submission.
Tools: Rejections.
Purchases and subscriptions
Add a yearly subscription with a two-week free trial in both stores.
Make 100 one-time offer codes for the yearly plan, valid until the end of the year.
Tools: In-app purchases and subscriptions.
Reviews and sales
Show me unanswered low-star reviews and draft polite replies.
How are downloads this month against last month?
Tools: Reviews and sales.
Marketing and In-App Events
Make a custom product page for people coming from our newsletter.
Set up an In-App Event for the summer challenge and send it to App Review.
Tools: Marketing and In-App Events.
GitHub
Set up builds on GitHub for this repository, and tell me what's mine to do.
Build every pull request labeled ploa:android.
Tools: GitHub.
The web
Put the web version of this app on Ploa at a free ploa.app address, and send me the testing link.
Release the tested web version.
Tools: The web: site and web app, The app's server.
Status and reports
Where does the app stand everywhere?
Why did the last release fail? Show me each step.
Tools: Status and reports.
Tips for good results
- Say the outcome, not the tools. "Send it to testers" is enough; the agent knows the order.
- Answer its questions. Price, countries, audience and contacts are yours. The agent waits rather than guess.
- Keep the stages board. Ask "where are we?" any time and it shows what's done, what's next and what's yours.
- Approvals are quick. When it asks, approve from the notification and tell the agent to carry on, or let it check by itself.
- "Kept in Ploa" means done. While Apple has something with App Review, Ploa keeps the change and sends it once Apple decides. Nothing to retry.
ploa_held_changeslists what's kept, and sends it now when you ask.