Every MCP tool
All 116 tools Ploa's MCP server gives your agent, in the order an app goes through them. You don't call them yourself: ask in plain words and the agent picks the tools. Each one says what it does, when it's used, whether it waits for you, and something you can ask.
A tool that asks you returns at once with a request. Nothing reaches the store until you approve it on the dashboard or from a notification, and the agent follows the answer with ploa_approval_status. If you made the agent autonomous, the same tools go straight through, still recorded under its name.
On the web (https://ploa.dev/mcp) the agent gets every tool not marked This computer, plus ploa_apps, and builds always run on GitHub. See Install and connect.
Start and setup
Where every new app begins: what's left in each store, who does each step, the app's ID, and how your agent works with you.
ploa_setup_guide
Works out where the app stands (signed in, app IDs, linked to Ploa, each store connected, the app made in each store, signing, store page, first build, Google Play's way to production) and says what's next, in order: who does each step (you or the agent), exactly what to do, and links that open the right page in App Store Connect, Play Console, Apple's developer site and Ploa. For an update, it says what a store turned down. Suggests a bundle ID and package name when there are none, and opens with the question of how your agent should work until you've answered it.
Use it at the start of every new app, and again after each step until nothing is left.
Set this app up for the App Store and Google Play with Ploa. Show me the stages and which steps are mine.
ploa_access
Who the agent's token belongs to, its level (read, draft, submit, production), whether its owner made it autonomous, and how you chose it works. With choose it records your answer: approvals at once; autonomous only as a request, with a link where you confirm it in Ploa. An agent can never make itself autonomous.
Use it once at the start, to record how you want the agent to work, and whenever you ask what it may do.
What are you allowed to do in Ploa with this token?
ploa_link
Links the app in this folder to Ploa, like ploa init: an Expo, Flutter, React Native, Capacitor, Android (Gradle) or Xcode app. Finds the app by its bundle ID or package name, or adds it with the workspace's store connections, and writes ploa.json (no secrets, fine to commit).
Use it once per app, when the guide says the folder isn't linked yet.
Link this folder to the app in Ploa.
ploa_apps
The workspace's apps with their IDs, bundle IDs and package names. On the web there's no project folder, so the agent names an app by its ID.
Use it first thing on the web, to pick the app.
Which apps do you see in Ploa?
ploa_appstore_register_bundle_id
Registers a new app's iOS bundle ID with Apple (nothing happens if it's already there), so all you do is pick it when you create the app in App Store Connect, a step only you can do.
Use it before you create a new app in App Store Connect.
Register the bundle ID at Apple so I can create the app.
ploa_app_icon_sync
Sends the project's icon to Ploa, so the dashboard shows it at once instead of after the next build reaches the stores. It also puts it (at 512×512) on a Google Play listing that has no icon yet; an icon Play already has stays.
Use it right after you change the icon, or to give a new app's Play listing its icon.
Send the new icon to Ploa.
ploa_android_upload_key_get
Whether Ploa holds the app's Android upload key: its alias, fingerprint, expiry and public certificate, which it can save to a file for Play Console's upload key reset. The key itself never leaves Ploa.
Use it when Play Console asks for the upload key's certificate, or to check which key signs the app.
Which Android upload key does Ploa sign this app with?
ploa_android_upload_key_save
Gives Ploa the Android upload key: a new one made inside the vault (for an app Play hasn't seen a build of yet), or an existing keystore from this computer (for an app Play already knows, say one EAS or Android Studio made). Replacing a key Ploa holds needs your explicit word, and the owners are told each time.
Use it once per Android app, before its first build through Ploa.
Make the Android upload key for this new app in Ploa's vault.
Steps only you can do
Some forms and declarations have no store API (App Privacy, most of Play's App content, an agreement only the Account Holder accepts). Ploa files each as a task in your approvals, with numbered steps and links, and the agent walks you through it.
ploa_person_tasks
The tasks waiting for you to do by hand, the ones Ploa filed when a store stopped a request and the ones agents asked for: each with its numbered steps, their links, and its page in Ploa.
Use it after a store refuses or holds something, and whenever you ask what's left for you.
What's left for me to do by hand in the stores?
ploa_ask_person
When the agent finds a step only you can do, puts it in your approvals as a task: numbered steps, each with the exact answer and its link, in English and Hebrew. Never for something the agent can do itself, and never to get around an approval.
Use it when the agent finds a console step Ploa hasn't filed yet.
Put the steps for Apple's EU trader status in my approvals and walk me through them.
Store details
Everything both stores ask for, as one set of answers: text per language, links, contact, category, age rating, price and countries, App Review's contact. The agent writes them from your code; they wait as drafts until they're sent. See The store page.
ploa_details_get
All the answers, the same as the Store details wizard on the dashboard, with what each store would refuse now, what looks like a mistake, and what's left for you to enter in a store's console, with links.
Use it before writing anything for the store page, and to see what a store would refuse.
What would each store refuse on the store page right now?
ploa_details_save
Saves answers as drafts for both stores, one step at a time: text in several languages at once, links, contact, Google Play's default language, category, age rating, price and countries, App Review's contact and the release option. What's New can be one text for both stores or each store's own. Returns what each store would still refuse.
Use it to write or change any part of the store page.
Write the store page in English and Hebrew from the app's code. Ask me about the price and countries first.
ploa_details_send
Checks every answer against both stores' rules and, when nothing would be refused, sends all drafts to App Store Connect and Google Play in one go. Normally you press Send on the Store details page; the agent sends only if it's autonomous. A price change becomes an approval.
Use it when the drafts are ready and the agent is autonomous; otherwise it tells you where to press Send.
Send the store details to both stores.
ploa_changes_get
Every draft waiting to be sent, store by store and field by field, and the changes Ploa keeps while Apple has the version with App Review.
Use it to see what will change in the stores before anything is sent.
What's waiting to be sent to the stores?
ploa_held_changes
The changes Ploa keeps while Apple has what they're for with App Review (text, screenshots, previews, a product's image, an event). Ploa sends them by itself once Apple decides; with send it asks to send them now.
Use it when App Review has decided and you'd rather not wait, or to see what's kept.
Which changes are kept for App Review? Send them now.
ploa_listing_get
The store listing of both stores per language: name, subtitle, descriptions, keywords, links, screenshots and videos in their order, each field's live value, draft and limit, and what each store still misses per language.
Use it before changing screenshots or a language's text, to get the IDs and limits.
Show me the Hebrew store listing with its screenshots.
ploa_listing_start_version
Apple takes text and screenshot changes only on a version being prepared. This creates the next one (1.2.0, say), copying the last version's text and screenshots.
Use it before changing the App Store page of an app that's already live.
Start App Store version 1.2.0.
ploa_appstore_price_points
Every price Apple offers in the app's base country, cheapest first (0 is free), each with the ID the price step takes.
Use it when you decide the app's price.
Which App Store prices can I choose from?
ploa_review_attachment_upload
Attaches a file for Apple's reviewers to the version being prepared, beside the review notes: a demo video of a flow they can't reach, or a document, up to 500 MB. It goes to Apple straight away; while the version is with App Review, Ploa keeps it until Apple decides.
Use it when App Review needs to see something it can't reach (hardware, a paid account, a place).
Attach this demo video for App Review.
ploa_review_attachment_remove
Removes one App Review attachment from the version being prepared.
Use it when an attachment is out of date.
Remove the old demo video from App Review's notes.
Privacy
What the app collects, answered once for both stores. Ploa makes Apple's App Privacy and Google Play's Data safety from it. Data safety can go to Google through Ploa; App Privacy you enter in App Store Connect.
ploa_privacy_hints
Reads the app's packages, config, purpose strings, Android permissions and privacy manifests, and returns hints: each known SDK and permission with the data it usually involves, where it was found, and what to check in the code. It doesn't decide the answers.
Use it before answering App Privacy and Data safety.
Work out from the code what data this app collects.
ploa_privacy_save
Saves what the app collects, once for both stores: Apple's data types with their purposes, whether each is linked and used for tracking, and Google's questions on encryption, deletion and accounts.
Use it once the answers are worked out, and when the app starts collecting something new.
Save the privacy answers for both stores.
ploa_play_data_safety_send
Sends the Data safety answers to Google Play, replacing the whole form in Play Console; Google then reviews it. Otherwise you press Send to Google Play on the dashboard.
Use it after the privacy answers are saved, when the agent is autonomous.
Send Data safety to Google Play.
Export compliance
Apple asks every iOS build whether the app uses encryption. Ploa keeps your answers, makes the declaration when one is needed, and answers each new build.
ploa_encryption_get
Your answers about the app's encryption, whether you need a declaration at Apple and which document, the declaration's review state, each build's answer, what the Info.plist should say, and the questions in plain words.
Use it before the first iOS build goes to testers outside your team.
Do we need an export compliance declaration for this app?
ploa_encryption_save
Saves your answers (no encryption, exempt, standard, proprietary or both, sold in France or not). They're your statements under US and French export rules, so the agent asks you and saves only what you said.
Use it after you answer the questions.
We only use HTTPS through iOS. Save that as our export compliance answer.
ploa_encryption_document
Uploads the document Apple asks for with a declaration (the CCATS, the French declaration), from a file you gave the agent. Kept in Ploa and sent with the declaration.
Use it only when your answers need a document.
Upload this CCATS PDF for the declaration.
ploa_encryption_declare
Sends the answers to Apple: makes the declaration when one is needed and attaches it to the builds, or answers "no non-exempt encryption" on them. Otherwise you press Send on the Store details page.
Use it once the answers are saved, when the agent is autonomous.
Send the export compliance answers to Apple.
Screenshots and videos
The exact sizes each store takes, captured from a simulator or emulator, checked, and uploaded in order. Videos are optional in both stores: the agent asks before making one.
ploa_screenshot_specs
Each store's screenshot rules per device: exact sizes or ranges, how many a set holds, the format, which sets each store asks for and which simulator gives each Apple size. Then which sets this app still needs, per language.
Use it before making screenshots.
Which screenshots do the stores still need from us?
ploa_screenshot_capture
Saves what a running iOS Simulator or Android emulator shows now, as a PNG, under the app's store/screenshots folder, and says which store sizes take it. It only captures: the app has to be on the right screen first.
Use it while the app runs on the screen you want in the store.
Capture the home screen on the iPhone 17 Pro Max simulator.
ploa_screenshot_web
Captures a page of the app's web build at exactly a store's size (an iPhone 6.9-inch by default) with Chrome or Edge in the background: iPhone screenshots on Windows or Linux, for an app whose web build is the same app.
Use it without a Mac, and check the result looks like the app on the phone.
Make iPhone screenshots from the web version.
ploa_screenshot_check
Checks image files on this computer against a store's rules (format, no transparency, size, file size) before anything is sent.
Use it before uploading screenshots made elsewhere.
Check these screenshots against the App Store's rules.
ploa_screenshot_upload
Uploads one screenshot or Google Play's feature graphic straight to the store listing, checked against the store's rules first. They go after the ones already there, so they're uploaded in order.
Use it once you agree with the screenshots.
Upload the iPhone screenshots in this order.
ploa_screenshot_remove
Removes one screenshot or graphic from the store listing.
Use it to replace or drop a screenshot.
Remove the third Android screenshot.
ploa_screenshot_order
Puts one App Store screenshot set in order. Google Play keeps the upload order, so there they're removed and uploaded again.
Use it when the App Store shows them in the wrong order.
Put the settings screenshot last on the App Store.
ploa_preview_upload
Uploads an App Store app preview video for one language and device size, checked against Apple's rules first (format, 15 to 30 seconds, resolution, size). Optional: only when you want one.
Use it when you've decided to have an app preview.
Upload this video as the iPhone app preview.
ploa_preview_remove
Removes one app preview from the version being prepared.
Use it to replace or drop a preview.
Remove the iPad app preview.
ploa_preview_order
Puts one set of up to three app previews in order.
Use it when you have more than one preview for a device size.
Show the short preview first.
ploa_preview_poster
Chooses the frame people see before an app preview plays.
Use it when the default frame (5 seconds in) isn't a good picture.
Use the frame at 2.5 seconds as the preview's poster.
Builds
Check the project, build it, sign it and send it to TestFlight and Google Play internal testing. Builds run on this computer, on GitHub, in Xcode Cloud or in your own Google Cloud. See Builds and signing.
ploa_preflight
Checks the project for what App Store Connect and Google Play would reject before a build: version and build numbers, bundle IDs, the icon, iOS purpose strings, the privacy manifest, export compliance, Play's target SDK, sensitive permissions and secrets committed to git. Each finding comes with its fix. (An app that isn't Expo isn't checked yet; it says so and the build can go ahead.)
Use it before every build.
Run preflight and fix what the stores would reject.
ploa_release_start
Builds and sends to testers: iOS to TestFlight, Android to internal testing, signed by Ploa. where picks the machine: this computer (the default), github, xcode-cloud, gcp, or auto (GitHub when it's ready there). Returns a release ID at once and runs in the background. It never goes to App Review or production. On the web it always builds on GitHub.
Use it every time you want a new build with testers.
Build iOS and Android and send them to testers.
ploa_release_status
Where a release stands: building, uploading, processed by Apple, on TestFlight or internal testing, or failed and why, with the build log's last lines while it builds on this computer.
Use it while a build runs, until testers have it.
Is the build on TestFlight yet?
ploa_release_stop
Stops a build that's still building, wherever it runs, like the dashboard's Stop. Two steps: the first call changes nothing and says what stopping does there; only after you say yes does it stop it. A web version still going up stops the same way.
Use it when a build was started by mistake or with the wrong code.
Stop the build that's running.
ploa_build_files_push
Finds the files a build on GitHub needs that git doesn't have (google-services.json, GoogleService-Info.plist, the .env files Expo loads) and sends them sealed to Ploa's vault. They wait for your one-tap approval; not approved within 24 hours, they're dropped. Their values never pass through the agent.
Use it before the first build on GitHub or in the cloud, when ploa_github_status says files are missing.
Send the build files GitHub is missing.
ploa_gap_report
Writes down for Ploa's team something Ploa doesn't do that the work ran into, instead of quietly working around it. It goes to Ploa's operators, not to you, and asks no one.
Use it when a step had to be done by hand.
Tell Ploa what it's missing here.
ploa_support_request
Drafts a message to Ploa's support for you to approve: it goes out under your name once you approve it, never by the agent alone.
Use it for a problem with Ploa itself, billing or a refund.
Write to Ploa's support about the failed upload.
ploa_build_diagnose
Why a build failed, as one cause and the step that fixes it, from the newest failed run and its log: disk or memory, a Gradle wrapper committed from Windows, the JDK or Android SDK, CocoaPods, an old Xcode, signing, a build number already used, Google Play's target SDK, missing files, GitHub's billing. When it was only the network or a busy store, it says to start the same build again.
Use it right after a build fails.
The build failed. Why, and what do we fix?
Testers
TestFlight groups, testers and beta review, and Google Play's testing tracks. See Testers.
ploa_testflight_get
TestFlight as App Store Connect has it: groups (internal, external, public link, builds), the beta information and contact, and what's missing before beta review. For one build, its What to Test, groups and export compliance; for one group, its testers and where each stands.
Use it before changing testers or sending a build to people outside your team.
Who is testing on TestFlight, and which build do they have?
ploa_testflight_save
One TestFlight change: make, change or delete a group, add or remove testers, What to Test, which groups get a build, the export compliance answer, beta information and contact, or send a build to beta review. Adding testers (Apple emails them) and beta review ask you first.
Use it to set up testing beyond your own team.
Make an external group called Friends with a public link, and write What to Test for the newest build.
ploa_play_testers_get
Google Play's internal, closed and open testing tracks with the release on each, the tester Google Groups, and the opt-in link.
Use it to see who can install a build from Google Play.
Which Google Groups test on the closed track?
ploa_play_testers_save
Adds and removes tester Google Groups on an internal or closed track, in one edit. Play's API takes only Google Groups; single email lists stay in Play Console.
Use it to give a group of people a testing track.
Add testers@googlegroups.com to the closed track.
App Review and production
Everything that puts a version in front of users waits for your approval. The agent prepares, asks, and follows your answer. See App Review and release.
ploa_release_submit_review
Asks to submit a TestFlight build for App Review, with the in-app products that are ready. With replace, swaps a newer build in for the one already with App Review, under one approval. A version App Review rejected goes back the same way, with a new build or the same one. With replyId, your reply to App Review goes in the version's notes first.
Use it when a build on TestFlight is ready for the App Store.
Submit the newest TestFlight build for App Review.
ploa_release_withdraw_review
Asks to take an iOS version out of App Review, so it's editable again, with its build still on TestFlight.
Use it when you found a problem after submitting.
Take the version out of App Review.
ploa_app_review_status
Where the App Store version stands with App Review (waiting, in review, approved, released in phases, rejected), its build and release option, earlier decisions, waiting requests, and the next steps with the tool for each.
Use it after submitting, and whenever you ask about App Review.
Where does the version stand with App Review?
ploa_appstore_release
Asks to release a version App Review approved that waits for you (manual release) onto the App Store, for everyone or in a 7-day phased release.
Use it when App Review approved and the version waits for you.
Release the approved version on the App Store in phases.
ploa_appstore_phased_release
Asks to pause, resume or finish an App Store phased release.
Use it during a 7-day phased release.
Pause the phased release.
ploa_appstore_release_type
Asks to change whether the app's App Store versions go out as soon as Apple approves them, or wait for you to release them. Ploa keeps it for the next versions too.
Use it any time: before App Review approves, it changes the version in review as well; after, it's for the next versions.
Hold the version after approval so I release it myself.
ploa_play_review_status
Where your production release stands with Google Play's review, and whether managed publishing holds what Google approved. Google has no API for managed publishing, so turning it on or off and publishing a held release are yours, in Play Console (the answer links it).
Use it after promoting to production on Google Play.
Where does the Android release stand with Google's review?
ploa_release_promote
Asks to move an Android release from internal testing to production (or beta, alpha), optionally as a staged rollout to a share of users.
Use it when the Android build has been tested.
Promote the Android release to production at 10%.
ploa_rollout
Asks to change an Android release's staged rollout on Google Play: widen it to a bigger share, halt it (people who have it keep it, no one new gets it), resume a halted one, or release it to everyone.
Use it when crashes rise after a release (halt), or when the rollout looks healthy.
Crashes went up after 2.3: halt the Android rollout.
ploa_schedule_release
Asks to release at a set time, on one store or both together: the version App Review approved onto the App Store, and the Android build to production. After you approve, each goes out at its time.
Use it for a launch day.
Release on both stores on Tuesday at 10:00.
ploa_min_version
Sets the lowest version people may keep using, per platform, with no SDK: the app asks Ploa at start and gets told to update below it, with your message and the store's link.
Use it when a version has a bug people must leave.
Ask everyone below 2.4 to update.
ploa_approval_status
Whether you approved or rejected a request, or haven't decided yet, and once approved, what the store said.
Use it after any tool that asks you.
Did I approve the App Review submission yet?
ploa_news
What happened in the last week that the agent should know: a store's review answer, a build that failed or reached testers, an approval you decided, a task you did, something a store turned down, a low review, a TestFlight build about to expire, a store connection that stopped working. Each with what to do next. New ones also come at the end of any Ploa tool's answer, once each.
Use it at the start of the work, and when you ask what's new.
What happened with my app since yesterday?
Rejections
What the stores turned down, why, and the way back.
ploa_review_rejection
Everything the stores turned down, in one place (App Store versions, builds, beta review, products, events, product pages, Play releases), with every reason their APIs give, the link to the full text, and what to do next. Apple's message isn't in its API: paste it to the agent and Ploa keeps it with the rejection.
Use it as soon as a store rejects something.
Why was the app rejected, and what do we need to fix?
ploa_app_review_reply
Keeps the reply to App Review's message, for when the message asks for an answer (a rejection that asks for a fix needs none: the fixed build is the answer). It shows under the version on the app's Release page with Copy reply and a link to the thread in App Store Connect, where you paste it and press Send: Apple's API can't send it. Passed to ploa_release_submit_review, it also goes in the version's notes.
Use it when App Review asks a question or you disagree with a rejection.
Draft a reply to App Review's question about the login.
In-app purchases and subscriptions
Products, subscriptions, prices, free trials, offers, offer codes and RevenueCat, straight in the stores. Anything that sets what people pay asks you first. See In-app purchases.
ploa_product_get
One product or subscription as its store has it: kind, state, names and descriptions per language, price, period and free trial, and what the store still needs before it can go on sale. With no product, what a new one needs.
Use it before making or changing a product.
What does the monthly subscription still need before App Review?
ploa_product_save
Creates or changes a product or subscription in one store: kind, ID, price, period, free trial, names and descriptions, and the App Store's group, review note and Family Sharing. A new product, a price or a free trial asks you; names and notes go straight through.
Use it to add a product or change its price, trial or text.
Make a monthly subscription at $4.99 with a one-week free trial on both stores.
ploa_product_job
How far a long product write got (an App Store subscription's price or offer, set country by country), and at the end what the store has or why it failed.
Use it after a price or trial change on the App Store, until it's done.
Is the new subscription price set in every country?
ploa_product_submit
Sends one product on its way to people: on the App Store to App Review (a first product goes with a version), on Google Play on sale.
Use it when the product has everything the store needs.
Send the yearly subscription to review.
ploa_product_review_screenshot
Uploads the screenshot App Review looks at for one App Store product: the screen where it's bought.
Use it before an App Store product goes to review.
Upload this paywall screenshot for the subscription's review.
ploa_product_image
Uploads the 1024×1024 image the App Store shows with one product. While the product is with App Review, Ploa keeps it and sends it once Apple decides.
Use it when you want the product promoted on the App Store.
Use this image for the Pro subscription on the App Store.
ploa_offers_get
A subscription's offers as its store has them: introductory offers and free trials, promotional, win-back and offer codes on the App Store; offers with phases and eligibility on Google Play.
Use it before making or ending an offer.
Which offers does the yearly subscription have?
ploa_offer_save
Creates, changes or ends an offer on one subscription. A new offer, a price, phases or putting one on sale ask you; ending one goes straight through.
Use it to run an introductory price, a win-back or a discount.
Give new subscribers the first month for $0.99.
ploa_offer_codes
The codes of one App Store offer code: list its batches, create one-time codes (up to 25,000 a batch) or a custom code, download a batch to a file (never printed), or end one.
Use it for a campaign that hands out codes.
Make 500 one-time codes for the launch offer and save them to codes.csv.
ploa_revenuecat_product_options
The RevenueCat project's entitlements and the packages of its current offering, with their IDs.
Use it before adding a store product to RevenueCat.
Which entitlements and packages does RevenueCat have?
ploa_revenuecat_create_product
Adds a store product to the app's RevenueCat project under the same ID, and optionally to an entitlement and a package, so purchases unlock what they should.
Use it after making a product in the stores, if the app uses RevenueCat.
Add the new subscription to RevenueCat's pro entitlement.
Reviews and sales
What people say and how the app sells. See Reviews, sales and marketing.
ploa_reviews_get
Reviews from both stores in one list, newest first, with stars, text, country or language, version and any reply, and each store's ratings summary. Google Play gives only about the last week's reviews with text.
Use it to see what people say, or find reviews to answer.
Show me this week's 1- and 2-star reviews that have no reply.
ploa_review_reply
Replies to a review in the store, where anyone can read it; a new reply replaces the old one.
Use it to answer a review.
Reply to that review: thank them and say the crash is fixed in 1.2.
ploa_sales
Downloads for the last 30 days against the 30 before, each store page's funnel (impressions, page views, conversion), and, for people and tokens allowed to see money, the proceeds and RevenueCat's numbers. A store whose reports can't be read says what to set up.
Use it to see how the app is doing.
How many downloads did we get this month compared to last month?
Marketing and In-App Events
The App Store's custom product pages, A/B tests of the product page, and In-App Events. Google Play's equivalents have no API and stay in Play Console.
ploa_marketing_get
The App Store's custom product pages (state, link, languages) and product page A/B tests (state, share of visitors, treatments). Apple's API gives no test results; those are in App Store Connect.
Use it before making a product page or a test.
Which custom product pages do we have?
ploa_marketing_save
One change to a custom product page or an A/B test: make, rename, text, a new version, remove; make a test, its treatments and languages, start or stop it. Sending a page or test to review, and starting or stopping a test, ask you.
Use it to run a campaign page or test a new icon or screenshots.
Make a product page for the summer campaign from the live page.
ploa_marketing_upload
Uploads a screenshot or app preview to a custom product page's or A/B test treatment's language.
Use it after making the page or treatment.
Upload these screenshots to the summer page in English.
ploa_events_get
The app's In-App Events, soonest first: state, dates, badge, text per language, media, and what an event still needs before App Review.
Use it before making or changing an event.
Which In-App Events are coming up?
ploa_event_save
Makes an In-App Event or changes a draft or rejected one: name, badge, deep link, dates per country, text per language.
Use it to plan an event in the App Store.
Make a live event for the cup final on June 12 with a deep link to the match screen.
ploa_event_media_upload
Uploads an event's card or details-page picture or video for one language.
Use it after the event's text is saved.
Upload this picture as the event's card.
ploa_event_submit
Asks to send a ready event to App Review. Once Apple approves it, the App Store shows it on its dates.
Use it when the event has its text and media.
Send the event to App Review.
GitHub
Builds on GitHub Actions, PR labels, Releases on GitHub and the store page from the repository. See GitHub.
ploa_github_status
Where builds on GitHub stand: GitHub connected, the repository, folder and release branch linked, Ploa's workflow on that branch, each platform's build state with its reason, where iOS builds, missing build files and GitHub minutes, ending with the next steps for you and the agent.
Use it before building on GitHub, and when a GitHub build won't start.
Can this app build on GitHub? What's missing?
ploa_github_setup
Does the agent's part of setting up builds on GitHub and asks you for yours: the link to connect GitHub, your approval to link the repository, folder and release branch, then Ploa's workflow on the branch (a pull request when the branch is protected).
Use it once per app, to build without your computer.
Set up builds on GitHub for this repository.
ploa_github_settings
Asks to change the app's GitHub settings: PR labels that build (ploa:android, ploa:ios, ploa:all), iOS on GitHub's Macs (only an owner), Releases on GitHub, the store page from the repo's store/ folder, and GitHub issues from the stores.
Use it to turn on label builds, releases or issues.
Turn on builds from PR labels and issues from store rejections.
The web: site and web app
The web is one more platform of the app, hosted by Ploa at a free address on ploa.app. Each version goes to testers first, and live only once you approve it. Ploa sells no domains: you can connect one you own. See Web: site and web app.
ploa_web_status
The workspace's web: each app's address, what it is (web app, showcase site or both, installable or not), its versions and where each stands, Ploa's checks on each, and the hosting room.
Use it first, before any web change.
Where does the app's website stand?
ploa_web_setup
Adds the web to an app at a free <name>.ploa.app, or changes what it is: the app itself in the browser, pages about the app, or both, and whether it's installable. The agent asks you which address and which kind.
Use it once, to give the app a web presence.
Add a showcase site for this app at myapp.ploa.app.
ploa_web_build
Builds the web app or site with its own framework (Expo, Next.js static export, Astro, SvelteKit, Vite, Flutter, plain HTML and many more) and sends it as a new version to its testing address. Ploa checks it first: no keys or .env, no form sending a password elsewhere, phones, sharing, the store links. Nothing goes live.
Use it for every new web version.
Build the website and send it to testers.
ploa_app_links
Makes links to the app's web open the app itself: writes the two files iOS and Android check (apple-app-site-association and assetlinks.json) from the bundle ID, the Apple team, the package name and the upload key's fingerprint Ploa already has, and says what the app's own config needs. You give Google Play's app signing fingerprint once, from Play Console. They go live with the next web version.
Use it when links shared from the app should open it, not the browser.
Make links to our site open the app on iPhone and Android.
ploa_web_testers
Who opens the testing addresses: testers by email (they sign in with a code), a password, or anyone with the link, and what to test.
Use it before sending a version to testers.
Let dana@example.com test the site, and ask her to check the sign-up form.
ploa_web_release
Asks to put a tested version live at the site's address and your domains, now or at a set time. Ploa reviews it again first.
Use it when testers are happy with a version.
Release the newest web version tonight at 22:00.
ploa_web_rollback
Puts the site back on an earlier live version, at once and with no review. Ploa keeps the last 10 versions.
Use it when a release went wrong.
Roll the site back to the previous version.
ploa_web_domain_add
Connects a domain you already own to a site and returns the DNS records you add where your domain's DNS is managed. Your plan sets how many domains connect.
Use it when you want the site at your own domain.
Connect www.example.com to the site.
ploa_web_domain_check
Checks the site's domains now: whether each record is in place and requests reach Ploa, with what's still missing.
Use it after adding the DNS records.
Is example.com connected yet?
The app's server
The server side of the web app: an API, scheduled jobs and a Postgres database on Google Cloud, in Ploa's cloud (on Pro and Team) or your own Google Cloud project. See Web: site and web app.
ploa_server_status
The app's server: where it stands, its address, the live version and last deploys, its variables (secrets by name only), its jobs, and what's needed when it's stopped. With no server, the kinds the workspace can have.
Use it first, before any server change.
Does this app have a server? Where does it stand?
ploa_server_create
Makes the app's server, in Ploa's cloud or in your own Google Cloud project (Ploa prints the commands you run once to let it in). The agent asks you which.
Use it once, when the web app needs a back end.
Make a server for this app in Ploa's cloud.
ploa_server_deploy
Sends the server's code as a new version, from the project's folder or from the linked GitHub repository, builds it on Google Cloud, runs the release command, and puts it live; the one before stays for rolling back.
Use it for every server change.
Deploy the API.
ploa_server_env
Sets or removes the server's environment variables; secrets are kept in Ploa's vault and never shown again. The agent never sets a secret you didn't give it.
Use it when the server needs a setting or a key.
Set LOG_LEVEL to debug on the server.
ploa_server_logs
The server's output and its jobs', newest first: what it printed, requests and crashes, filtered by words or job.
Use it when something on the server misbehaves.
Show me the server's errors from the last hour.
ploa_server_run
Runs a command once with the live version, its variables and database (a seed script, a one-off fix). Its output is in the logs.
Use it for a one-off task on the live server.
Run the seed script on the server.
ploa_server_jobs
Adds, changes or removes a scheduled job (cron, in UTC, at most every 5 minutes).
Use it for work that runs on a schedule.
Run the cleanup script every night at 3:00 UTC.
ploa_db_query
Runs SQL on the server's database. Read-only, unless write is set, which needs the production level.
Use it to look at data, or fix a row by hand.
How many users signed up this week?
Status and reports
Where everything stands, and how each release went.
ploa_shipping_report
One report of where the app stands everywhere: the newest TestFlight build and App Store version, Play's tracks and rollout, what waits for approval, and the last run.
Use it first, for "how is the app doing?" or "what's next?".
Where does the app stand in both stores?
ploa_what_now
Every app of the workspace in one answer, like the home page's What now: requests waiting for your approval, builds that failed or stopped, and what's on its way.
Use it at the start of the work, and when you ask what's going on.
What's waiting for me across all the apps?
ploa_activity
What was done in the app, newest first, from Ploa's audit log: store details sent, builds, approvals asked and decided, keys and settings, each with who did it (you, an agent by name, a token or Ploa) and when.
Use it when picking up work someone else started, or to find who changed something.
Who changed the store page this week?
ploa_size_report
Each recent build's size per platform, the change from the build before, and a warning when an iPhone build passes 200 MB, past which iPhones ask before downloading over cellular.
Use it after a build that grew, or before adding a big library or asset.
Why did the app get bigger?
ploa_store_deadlines
The stores' rules with a date that Ploa knows (the Xcode a build must come from, Google Play's target SDK, Play's trader status), and each app against them.
Use it before planning a release.
Is anything at the stores coming up that touches our apps?
ploa_usage_get
What the workspace uses of its plan: apps and members against its counts, and the web's hosting room. Builds on your computer, on GitHub, in Xcode Cloud or in your Google Cloud never count.
Use it before adding an app or inviting someone.
How many more apps can we add on our plan?
ploa_status
What the stores have right now: recent iOS builds and their processing, App Store versions, and Google Play's tracks with their releases and rollout.
Use it to see the stores' own view, apart from Ploa's.
What do the stores have for this app right now?
ploa_runs
The app's recent release runs, each step with its duration (build, upload, signing, Apple's processing or Google Play, the testing track, the approval), who started it and the commit.
Use it to find out why a release failed or where it got stuck.
Why did the last release fail?
ploa_quality
How stable released versions are. Google Play: crash and ANR rates over 28 days against Play's thresholds, per version, and the top crashes. App Store: Xcode's metrics (launch, hangs, memory) with Apple's regressions.
Use it before widening a rollout or releasing to everyone.
Is the new Android version stable enough to widen the rollout?
ploa_release_changes
The pull requests and commits between two releases, from the app's GitHub repository, with titles, authors and descriptions.
Use it when writing What's New.
Write What's New from the pull requests since the last version.