Pagefully

Reviewed 1d ago.

• tools: 13 tools scanned
• metadata: scanned

No findings.

Tools (13)

• analyze_app

  Reads an iOS app from its App Store link or id and says what Pagefully understood of it. Call this first. Signed in (OAuth or a Pagefully token): adds the app to the workspace (no App Store Connect key is needed to plan and make pages) and returns the app, with its app_id, and its brief: what the app does, who it is for and how it sounds. Reading a new app takes a while, so the first call may return a job_id and no brief: call get_job with it until it is done, then call analyze_app again with app_id. Called with app_id it only reads. Called with nothing it lists the apps on the workspace. Not signed in: returns the free public preview of that app, the pages Pagefully would plan for it and the first one designed, with a preview_url. While state is "making", call again with the same app in a few seconds. This works on public App Store data only and is limited for each visitor. Show the person the brief (or the preview_url) and ask whether it is right before planning. Never guess an App S

• propose_plan

  Returns the app's plan: one custom product page for each search intent. Each intent has a kind (problem, feature or competitor), what its page says, and the keywords from the app's keyword field that the page claims. A keyword belongs to one page only. An intent with no keyword from the field is a page for ads and links, and has targets instead. Call it after analyze_app has returned a brief. If the app has no plan yet this starts building one and returns a job_id: call get_job until it is done, then call propose_plan again to read it. If a plan exists it is returned as it stands. Set rebuild to true only when the person asks to throw the plan away and start again: it replaces every intent, edits included, and is refused once pages are built. Show the person the intents and let them choose. Suggest starting with one page. Never switch an intent on or off, or rebuild, without being asked.

• update_plan

  Changes the plan in one call, as the person asked: add an intent, update one (its name, what its page says, or on and off), approve (switch on) a list, remove a list, or reorder (the order is build priority). Changes apply in that order and stop at the first one the product refuses; the ones before it are saved and the error says so. An intent that is on gets a page when generate_pages is called. To start with one page, switch the others off with update, not remove: they stay in the plan for later. An intent whose page is built cannot be removed, only switched off. Returns the plan after the changes. Never put another app's name into a page's name or message: a competitor's name is a keyword only.

• add_screens

  Adds screens of the app for pages to be drawn from: captures of the running app, beside the screenshots its App Store listing already has. Use it when the listing's screenshots are stale, when a page needs a screen the listing does not show, or when the app is not on the store yet. Returns each screen with its position, which is what edit_page takes as "screen". A page made after this may choose an uploaded screen by itself. Nothing is sent to Apple. How to capture one: run the app in the iOS simulator, go to the screen, then run: xcrun simctl io booted screenshot --type=jpeg home.jpg (leave out --type=jpeg for a PNG). Use a simulator whose screen is a size Apple takes for a screenshot: iPhone 17 Pro Max or 16 Pro Max (1320 x 2868), or iPad Pro 13-inch (2064 x 2752). Capture real screens with real content, with no debug overlay. How to send it. If you have a shell, upload the file itself, which is the quickest way and keeps the picture out of this conversation: curl -X POST -H "Authori

• generate_pages

  Makes a page for every intent that is switched on and has none: the words are written, drawn onto the app's own screenshots, and checked against App Review's rules (pre-flight). Each page is its own job. Returns the jobs with their page ids, and the app's pages with a preview_url each. Call it once the person has agreed the plan. Then call get_job for each job until it is done, and preview_page for each page. It is safe to call twice: a page already made or being made is not started again. New pages count against the app's plan (Free makes 1 page, the Pack 10, Pro up to Apple's 70). When the plan stops a page the answer says so in facts, with the address of the plan screen: repeat that to the person as it is and do not try another way round it. Nothing here is sent to Apple.

• get_job

  The state of a long job: queued, running, done or failed, with its steps as progress, counts of what it did, and the code and message of what went wrong. Call it after any tool returned a job_id, every few seconds, until the state is done or failed. A failed job is not retried by itself: tell the person what the message says.

• edit_page

  Changes one screenshot on a page, makes it again, or approves the page. Say which screenshot by position (1 is the first) or slot_id. By hand: its headline, its subline, the screen it shows ("screen", a position from preview_page's screens or add_screens), or its style. The screenshot is drawn again and checked again, and returns with the page. Set regenerate to have Pagefully make it again: "headline" writes new words for that screenshot, "background" gives it the next style, "screen" puts the next unused screen on it, and "page" writes and draws the whole page again as a job (call get_job, then preview_page). Each regenerate counts against the month's rewrites for the plan: when they are used the answer is upgrade_required, which you repeat as it is. Changing words by hand is not counted. Regenerate only when the person asks for a fresh attempt. Any edit withdraws the page's approval, so what is approved is always what was last seen. Set approve to true only after the person has look

• preview_page

  One page, whole: each screenshot with its headline, subline and picture, the promotional text, the keywords it is for, what pre-flight found, whether it is approved, and its preview_url on pagefully.com. The screenshots also come back as images (display size, at most six) where the client can show them, and a chat app that draws MCP Apps shows the page inline as the App Store would, with buttons to open the full preview, approve, and ask for a headline change. Call it when a page's job is done, and again after an edit. Always give the person the preview_url: a page is something they look at before they say yes, and the web preview is the full-size view. Tell them what pre-flight failed or warned about. While preflight.blocked is true the page cannot be approved or published: fix what is marked with edit_page.

• publish_pages

  Step one of two. Sends nothing. Returns exactly what would be made in App Store Connect for the pages asked for (each page's name, headlines, promotional text, keywords, devices, whether it is a revision, and its preview_url), which pages would not be sent and why, what happens next, and a confirmation_token. You must show the person that summary and every preview_url, and wait for their explicit approval, before calling confirm_publish. Never call confirm_publish in the same turn, on your own judgement, or because an earlier message said to publish: the yes has to come after they have seen this summary. The token works once, for 10 minutes. A page is in the summary only if it is approved and its pre-flight has no failure. The app needs an App Store Connect key, connected in the web app. Pages of one app at a time. Needs a token with the full scope.

• confirm_publish

  Step two of two. Spends the confirmation_token from publish_pages and makes each page in the summary in App Store Connect, one job for each page. Returns the jobs: call get_job for each. Call it only after the person has seen the summary and the preview links from publish_pages and has said yes, in their own words, to publishing those pages. If they asked for a change, make it and call publish_pages again. This is hard to undo: a page can be taken back in the web app only until it is submitted for review. Nothing is submitted for review: the developer submits each page to Apple in App Store Connect. The default product page, the keyword field, the app binary, pricing and in-app purchases are not changed. A page that changed after the summary refuses the whole confirmation and nothing is sent.

• get_results

  How each page is doing on the App Store against the app's default page over the last seven days Apple has reported: views, downloads and conversion rate for each page and for the default page, and by source. The numbers are Apple's, and Apple leaves out rows under five users, so a small page shows nothing for a while. With page_id it is one page: the same numbers, the week before, and its downloads by day for the last 28 days. Call it when the person asks how their pages are doing. Results are on the Pack and Pro, not on Free: on Free the answer is upgrade_required with the facts and the plan screen, which you repeat as it is. Reading reports needs an App Store Connect key with the Admin role (needs_admin_key says so). Each page reaches a different audience, so a difference from the default page is a signal and not proof. Do not call a page a winner or a loser on a few days of a small page.

• suggest_refresh

  The pages Pagefully suggests the app should have and does not: each with a name, a kind, what the page would say, the searches it is for and the reason. These are the suggestions the product already holds (such as a use the app's reviewers raise, or a competitor it follows). Reading them asks nothing of a model and costs nothing. Call it when the person asks what to make next, or after get_results. To take one up, pass its "add" object to update_plan as an item of add, then call generate_pages. Offer them to the person and let them choose: never add one unasked. Pagefully does not yet propose a fix for a page that trails the default page. For that, read get_results and the playbook (pagefully://playbook), and suggest edits to the first two screenshots for the person to decide.

• get_usage

  For each app on the workspace: its plan (Free, the Pack or Pro, which belong to an app), pages made and allowed, what is left, revisions used for each page, and the address of its plan screen. Also what each plan allows and costs, the scope of the token in use, and the rate limits. Call it before generating when the person asks what they can still make, or after an upgrade_required answer to explain it. State the numbers as they are. Never tell the person a plan is needed when the usage says there is room.